[bfprog] Packaging and Importing Custom Python Code

[Forrest Thiessen]

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

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.

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?

Best regards,

--Forrest



Anton Jansen wrote:

> Hi list,
>
> I couldn't restrain myself from responsing to this e-mail, seems that
> my software architecture research is good for something in this world
> ;-)  Anyway, I want to respond to the issue pointed out by Forrest:
>
> Forrest Thiessen wrote:
> "...
> It seems to me that what's missing here is something in the default
> code that (as one way of doing it) would import any custom Python
> packages contained in a certain directory, so that all you need to do
> to add or change features in the game is to drop the new packages into
> that directory and restart the server. Since that's not in the default
> server  code, I suggest the way to do this is to have ONE standard
> modification to the default code that adds this capability; everybody
> makes that one standard change, and from then on, everyone just pops
> any changes they want cleanly into the "custom" directory, and away
> you go.
> "
>
> Basically what you propose is a plugin framework, like metamod for
> HL2. This plugin should allow multiple server side "mods" to be run
> simultaniously. Important for this plugin framework to be succesfull
> is completeness,  good documentation, and  a  non-invasive licensing
> sheme (e.g. BSD).  I would be willing to spend some of my precious
> free time on this endavour.
>
> The first step seems to me to get some requirements, what do we want
> todo with these server side mods?  Who is interrested in developing
> such a thing? Who is gonna use it?
>
>> Of course, EA/DICE are the logical people to make this change, but
>> wen haven't had any hints yet, that I know of, as to how receptive
>> they are to such things (or whether they are even on this mailing list).
>>
> It would be very nice if Dice took up this challenge, but I'm afraid
> it's out of their scope.
>
> With kind regards,
>
> Anton Jansen
> _______________________________________________
> BFProg mailing list
> BFProg at lists.matureasskickers.net
> http://lists.matureasskickers.net/mailman/listinfo/bfprog