[bfprog] Packaging and Importing Custom Python Code

[Anton Jansen]

Forrest Thiessen wrote:

>Wow, that's a great insight, Anton! I hadn't thought of the metamod
>analogy, but it is especially accurate! A metamod for BF2 is exactly
>what we're after!
>  
>
I already thought so.

>I think the fact that we're working in Python, however, as opposed to
>the C/C++ of metamod and Half Life, will make the whole adventure
>dramatically simpler--being a dynamic language, Python does most of the
>work for us, for free; I was actually fantasizing that this might be
>something that could be written and testing in a few hours--but that's
>obviously someone speaking who hasn't tried it yet! (I'll see if I can
>find the time later today. . .)
>  
>
I had the same idea, python is an interperted language. I know you can 
even change classes on run-time, something I truly miss for my current 
Java exploits ;-) However, I don't think it's THAT simple, as there will 
be plenty of small nifty irritating little things to think about.

>I agree about BSD licensing, with one caveat: at least part of the code
>must consist of a modification to the core BF2 Python code, which we
>have no rights to.  There's no licensing information in that code, so
>I'll have to go back and look at the EA EULA again to see if there are
>any landmines in it.
>  
>
Yes, we need to have the permission before we start, otherwise this can 
turn into a real mess.

>I'd suggest that to simplify licensing issues (assuming the EULA allows
>this), the way to go would be to add just one  lines to bf2.__init__: a
>line that imports our plug-in framework package.  The package itself
>would be BSD-licensed; the single-line change to bf2.__init__ minimizes
>the need to touch EA/DICE's code, and would presumably (hopefully?) not
>infringe on whatever their EULA says.
>  
>
Yes, that were my thoughts. Minimize the influence of our BF2Metamod 
(like the name?) on the original code as much as possible. Done right, 
this makes maintenance a lot easier ...

>Requirements: I see two levels of plug-ins: (1) those that change basic
>BF2 functionality; for example, the Brigham Stevens autobalance
>modification, and (2) those associated with mods.  For (1) I suggest we
>use a new folder: Battlefield 2 Server/python/custom; our plug-in
>framework (actually the __init__.py module for the package) looks up the
>contents of that directory, which could be Python modules or packages,
>and dynamically imports them--job done.
>
>For situation (2): DICE already has a system wherein each mod is
>encapsulated in it's own set of directories (under Battlefield 2
>Server/mods), and a mod developer can hook their Python code in by
>putting the necessary imports inside the mod's game.scoringCommon
>module, but that's tacky--a module named "game.scoringCommon" should
>contain scoring logic, not general mod logic.  So I suggest that it
>would be a simple matter to extend the mechanism for situation (1) so
>that the plug-in framework would also dynamically import any modules or
>packages in the directory Battlefield 2 Server/mods/<mod
>name>/python/custom. That way everything would be consistent.
>
>Once that basic capability was in place, any developer could do,
>litterally, anything they needed to; the only remaining issue would be
>whether it would be possible to take any further steps to limit the
>"damage" that one developer might do to another.  For example, Brigham's
>autobalance mod could be turned into a module that gets dropped into the
>custom folder; it would just redefine the
>admin.standard_admin.autobalance.onPlayerDeath method.  Well, what if
>another developer, trying to accomplish something entirely different,
>had their own custom module that also modified that same method?  I
>guess my view at the moment is that that's just the way life is in the
>big city of Object Oriented Dynamic Languages--that there's not much we
>could do about that kind of an overlap problem from the inside of a
>plug-in framework package--not without doing a REALLY LARGE amount of
>Ph.D.-scale work.
>
>Are there other requirements I'm not seeing?
>  
>
Yes quite a few, let me make a list ;-)

Stakeholders:
- BF2Metamod developers
- Server side mod developers
- Game mod developers
- Server admins (e.g. GSPs)
- EA/Dice
- more?

Functional requirements:
BF2Metamod should:
1. Support both server side scripts, as well as game mods.
2. Allow for multiple mods to be run simultaniously
3. Easy deployment and installation
4. Allow for run-time reconfiguration of the mods being active

Optional stuff:

5. A logging infrastructure for debugging
6. Automatic updating of installed mods/metamod

Non-functional requirements:
1. Stability, a mod crashing in meta-mod should not interfere with the 
others
2. Flexibility, the BF2Metamod should support the BF2 engine as far as 
possible
3. Useability, configuration and installation of BF2Metamod and Mods 
using it should be automated. (No config files hacking please).
4. Maintainability, the BF2Metamod should be easy to maintain, as 
patches will evolve the BF2 engine.
5. Performance, the BF2Metamod should not induce a significant 
performance penalty on the BF2 engine.


With kind regards,

Anton Jansen