[MUD-Dev] Embedding Python

[Todd McKimmey]

----- Original Message -----
From: "Oliver Jowett" <icecube at ihug.co.nz>
To: <mud-dev at kanga.nu>
Sent: Thursday, March 23, 2000 3:42 PM
Subject: Re: [MUD-Dev] Embedding Python


> In summary, microthreads look like they can provide:
>
> - support for multiple (potentially a large number) of Python execution
>   threads, without requiring the server to be natively multithreaded.

My work-around is likely horribly lazy in the eyes of a language-lawyer, but
I know the system I'm going to be running it on is going to 1) be exclusive
to the game itself, and 2) have at least 128mb if not 256mb of memory so
I've taken some liberty in making use of what it's going to be running on.

Briefly running over the setup ... As far as python itself goes, I'm partial
to smaller functions than larger ones, so doing wait states is implemented a
series of related pulse based callbacks. All python script hooks can be
called with a single script-based python object that is definable at the
time the hook is generated. Of course the object can be a list so any number
of arguments can be passed as long as they're a sequence type. On top of
that, the hooks into the system for all functions are done by a reference to
an object id (all entities in game have a unique ID, tracked on an STL map
with some caching built in for speed). Therefore if the object ceases to be,
any further calls will simply be ignored or, depending on where the script
hook is sitting, may be discarded entirely.

So a sample conversational code might look like:

def MyConversation(them, us, builderparm):
  if bulderparm != None:
    myInterfaceModule.Interpret(us, "say Welcome to my shop.")
    myInterfaceModule.Callback(us, 4, MyConversation, 1)
  else:
     if builderparm == 1:
       myInterfaceModule.Interpret(us, "say Have a look around, let me know
if I can be of further help.")
       myInterfaceModule.Callback(us, 4, MyConversation, 2)
     elif builderparm == 2:
        ... continue conversation

Since additional callbacks to the same function (or newly initialized ones)
are referenced from different points in the code, the script can be in use
simultaneously (or, via a series of simple checks, not executed again until
the first one has finished). The above code does have a sort of 'messiness'
to it, but I've also written python class wrappers around it as well if
people want a different interface. Not 100% efficient, but it works and
maintains the C++ code without having to resort to multiple threads (which I
hate debugging) or constantly verifying that the objects you're manipulating
are still hanging around in the code.

In reference to some issues in the original thread:

There is a code interface for c++/embedded python but the URL escapes me
right now, and it serves to alleviate a lot of the reference counting
headaches and doesn't require patching the actual python source at all. If I
can drum it up, I'll pass it off.

> .. and the implementation on top of SP is more likely to become mainstream
> (and appears easier to extend) than the custom version.

It'd be incredible if python were easier to embed than it already is. After
the disasters of trying to write my own scripting language, the ease of
embedding python as-is was a dream come true.

-Todd





_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev