[bfprog] OS Module Nerfed, Plus

[Anton Jansen]

Forrest Thiessen wrote:

>>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
>
>_______________________________________________
>BFProg mailing list
>BFProg at lists.matureasskickers.net
>http://lists.matureasskickers.net/mailman/listinfo/bfprog
>  
>
Hi Forrest,

It looks good, I will spend some time on this tomorrow. I need some 
sleep first ;-)

With kind regards,

Anton Jansen