[bfprog] OS Module Nerfed, Plus

[Forrest Thiessen]

>
>
>However, I don't think it's THAT simple, as there will 
>be plenty of small nifty irritating little things to think about.
>

Ugh.  I just found one of those "nifty irritating little things".  I've
been experimenting with BF2, poking and proding things from within
Python scripts to try to figure out how they work.  I finally decided it
would facilitate this work to use the script I posted earlier that
imports everything it finds in a "custom" directory.  Guess what?  My
script, which works just fine under regular Python, doesn't work under
the BF2-embedded Python interpreter.

The problem: it appears that DICE "neutered" the os module, so you can
"import os", but when you try to do "os.listdir("whatever")", the server
aborts with an error, saying there is no such method.  I tried some of
the os methods and attributes, and I can't get them to work, either.

In retrospect, this probably makes sense: the os module lets Python
manipulate the local operating system; os.system(), for example, lets
you execute arbitrary operating system commands.  For security reasons,
I guess I could understand someone not wanting Battlefield 2 scripts to
be able to do this.

If true, this means that there is no (obvious) way of finding out what
modules are in a directory, and if you don't know a modules name, you
can't import it.

Still there are several possible ways out of this:

1. While DICE has the Python standard library already packaged up and
available for the embedded interpreter, it might be possible to include
a working os module with the BF2Metamod installation, and then import
that to get around this problem.

2. The worst-case scenario: implement a registration scheme for custom
modules. Just include a text file in the "custom" directory that
includes the names of all the custom modules that should be imported. 
Instead of just dropping custom modules into a folder, you would then
also need to add their names to the text file.

I'll keep messing around with it.


You asked for comments on your proposed requirements; sorry for the
delay, but here are mine:

>Functional requirements:
>BF2Metamod should:
>1. Support both server side scripts, as well as game mods.
>  
>
Not a problem; I've given this one some thought, and think the best way
to implement this is as two packages: one goes in the python/bf2
directory and contains customizations for the server in general; the
other goes in the mod directory (for example, mods/bf2/python) and
contains customizations for that specific mod.  Both packages have the
same __init__.py code.  Then, instead of adding just one line to
python/bf2/__init__.py, you add these two lines:
  import bf2.custom
  __import__.(bf2.gameLogic.getModDir()).custom
. . .or something like that--I need to do some experimenting!  The point
is that the first line imports the overall server custom package, and
the second dynamically imports the custom package specific to the mod
being run.

>2. Allow for multiple mods to be run simultaniously
>  
>
The script I proposed already does this.  No problem.

>3. Easy deployment and installation
>  
>
This one is a little tricky--the whole nature of the problem requires
modifying DICE's python/bf2/__init__.py file, so we need to do one of
the following, all of which are yucky:

a. Tell the user what lines to add to what file; because this is Python
this is especially tricky--the lines in question need to be indented
just right, or the game will crash with a Python error, and the lines in
question need to be added at the end of the file, just after several
lines with different levels of indentation, so it liable to be confusing
for people.

b. Include an installation script that makes the change for people; also
tricky if people have made any other changes to the file, and may have
problems if/when EA updates the original file, but is probably do-able.

c. Include a full copy of the file with the changes already made, so
they just drop the replacement file in, overwriting the original.  This
is probably easiest thing to do, but still suffers from problems if
people have made other customizations and from conflicts when EA does
updates.

>4. Allow for run-time reconfiguration of the mods being active
>  
>
If by "mods" you mean the plug-in customized Python modules (as opposed
to "mods" like "bf2"), this would be a real headache.  Of course, this
being Python, it's certainly possible--you can change running Python
programs while they're executing and have everything work, if you're
careful.  The details, though, could get really, really nasty in this case.

I suppose we could require the writers of plug-ins to include an
"uninstall" method, and then watch for console commands via
pythonHost.sendCommand (although I haven't figured out how to get this
to work, yet), and then call the appropriate uninstall methods. . . 
I'll give it some thought.

>Optional stuff:
>
>5. A logging infrastructure for debugging
>  
>
I think this is best handled by a plug-in.  It's easy to do, just four
lines:
  import sys
  logFile = open('mylog.log', 'a')
  sys.stdout = logFile
  sys.stderr = logFile

Put this in a .py file, drop it in the "custom" directory (and maybe
register it, as described above), and you've got a debugging logging
facility.

We could make this plug-in a standard part of the BF2Metamod distribution.

>6. Automatic updating of installed mods/metamod
>  
>
If there isn't a fix for the emasculated os module, it wouldn't be
possible to do this within the game itself--it would have to be done by
an external program.  I'm also leary of the security issues it could
raise, so consider me skeptical about this one.

>Non-functional requirements:
>1. Stability, a mod crashing in meta-mod should not interfere with the 
>others
>  
>
I don't think this is possible with the existing BF2/Python
architecture.  As things stand, any uncaught exception anywhere in
anybody's Python code causes the whole game to come crashing down. 
Unless we want to implement an event callback wrapper scheme (MAJOR
undertaking) and a whole new level of handler registration, there's no
way we could catch people's exceptions for them.

>2. Flexibility, the BF2Metamod should support the BF2 engine as far as 
>possible
>  
>
Already there. . . we may even be able to go a little farther than what
the BF2 engine allows. . . for example, if we replaced the broken os
module. . .

>3. Useability, configuration and installation of BF2Metamod and Mods 
>using it should be automated. (No config files hacking please).
>  
>
Maybe. . . see comments above about installation.

>4. Maintainability, the BF2Metamod should be easy to maintain, as 
>patches will evolve the BF2 engine.
>  
>
I think the biggest problem (maybe only problem) in this area is that
for this to work a few lines need to be tacked into one of the DICE
files. . . and the DICE files will change over time.  To really solve
this issue, we need DICE to do what they should have done originally,
and that is to put something like BF2Metamod into the code themselves.

>5. Performance, the BF2Metamod should not induce a significant 
>performance penalty on the BF2 engine.
>
Already done; the script I proposed needs a few microseconds during
server start-up, and then is out of the picture completely.  If we added
an uninstall capability, it would just need an extra few microseconds
every time a console command was typed.


--Forrest