From [email protected] on April 24, 2007 08:18:40

Well what do ya know. You've already started posting issues. :)

Something like tinymux's command objects might be a good way to implement this. We'd
have to either make a new object type or do the same thing Brazil did with TinyMUX -
make a special room that is checked for objects with commands attached to them, a la
the parent system. With the new object type, it means people could make their own
personal command objects, and just carry them around - letting them clone the object
to give others a copy of a command. This way, the command's access is limited to
that of the player object that owns (or perhaps "carries") the object. I could see
both good things (and nightmares, to be fair) coming from a mux/mud that lets players
trade their own neat little commands with each other.

Lots of potential, lots of nightmares. :) I think we'd want a permissions system in
place before implementing this, however.

from evennia.

From [email protected] on April 24, 2007 08:34:31

The big deal here is that instead of softcode, we'll be using an external scripting
language. Evennia as a codebase will side a lot more with extension and development
by admins, rather than building and coding by the entire playerbase (as is the case
with many MUX/MUSH). While privileged players may create rooms, objects, exits, etc.,
they won't be able to script much of anything in-game. I absolutely loath softcode
and really want to stay as far from it as possible with this.

So we basically need a very pluggable architecture to associate certain objects with
certain external scripts. From there we can worry about command propagation, which
shouldn't be terribly hard to address. If we can build it in such a way as to allow
admins to use a number of different languages to script objects, even better. But I'd
like to at least initially make Python the preferred language, as it's really well
suited to this and is also obviously the codebase's native language.

As far as details, I'm thinking we'll have a directory (with sorted sub-directories)
of python files (the equivalent of MUX parent objects). The game will be aware of
these and allow for updating and adding new ones without restarting. Objects can be
associated (parented) with some of these generic object types, and preferably support
sub-classing/overriding. I'd like to eventually tie in a web-based script editor of
some sort so admins can work on things from a web browser so they don't have to have
shell access to work (many head admins are wary of handing access out, myself included).

So things that would need to happen include:

1. Coming up with a scripting API for the "parent" scripts to interact with the game
   with.
2. Building this in a manner where we can drop other languages in down the road if
   there's interest.
3. Making it very robust, as painless as possible, and simple.

from evennia.

From [email protected] on April 25, 2007 08:08:18

Ah, I've always associated softcode as a "scripting language" of its own. I also
have never really liked it. It's great for what it does, but it's not exactly a
friendly language (I hope Brazil doesn't read this :).

I've already spoken with Brazil and the tinymux dev community in the past about using
another language or allowing the use of another language for softcode. My
suggestions back then were PHP and Python.

So the API should have a connection to permissions, meaning it will have to tie in
with django somehow (we can use a proxy pattern or something along those lines if we
want to keep it as separate as possible). I think the best bet would be to have a
base "Script" class that they should extend, and base the API around that. It would
mean API changes for a while until it was robust enough for production use. Maybe
have some starter methods that handle basic permission checks/requirements, database
hits (if necessary), and tie-ins to the different kinds of "emit".

Maybe something like:

class Script(object):

Required permission to use this script

__permission_required = None

def init(self):
# Runtime init here

def has_access(self, user):
# check if user has self.__permission_required

The hard question will come later when you add caching to the system as to whether or
not we cache the script objects at all. Since it's desirable to have live changes of
the scripts, caching will probably have to be right-out, but I could see a benefit
for a script running indefinitely in the "background" (say, a weather system), and
only running init once. Maybe we can take some examples from livecoding for this

• have the API check the files for changes, and re-init them somehow after saving
  state data.

from evennia.

From [email protected] on April 25, 2007 19:59:12

Since this is such a critical issue, I'm going to put this on hold until we get more
people involved in the project to offer input and assist in a sturdy implementation.
We'll get the rest of the API stabilized and work towards this.

Status: Deferred

from evennia.

From [email protected] on May 27, 2007 10:37:28

Labels: Maintainability

from evennia.

From [email protected] on June 06, 2007 06:43:49

The beginnings of this are in and only need refining. See scripthandler.py for the
glue, and cmd_look for a good example of how this hooks in (at the end of the
function). I'm going to close this issue, we'll handle refining and enhancements via
other issues.

Status: Implemented
Labels: Milestone-Alpha

from evennia.