[MUD-Dev] NWN gets more MUD-like (again)

Smith Smith
Fri Feb 7 09:56:40 New Zealand Daylight Time 2003

On Thursday, February 06, Hans-Henrik Staerfeldt wrote:

> However i love to make things needlessly complicated and unable to
> handle the server being patched unless you rewrite your wrapper
> from scratch,

I've only barely gotten started writing my own version of what the
Avlis group has working, but the scheme that I think they're using
(and the one that I'm designing around) wouldn't have to be
rewritten for patched versions of Neverwinter Nights. Since the
shared memory area is discovered at runtime (instead of relying on
load location like many "trainer" style applications), I don't think
any changes will be required for future versions.

Bioware could do a few things to thwart this method of IPC.

  1. They could store string data written by the scripting system
  non- continuously.

  2. They could aggressively re-allocate storage for variables in
  use by the scripting system.

  3. They could encrypt the storage in use by the scripting system.

I think all these methods would increase overhead within the
Neverwinter Nights scripting system intollerably; hopefully,
Bioware's not interested enough in thwarting user-extension to do

> why is it that sockets "just won't happen"??  Socket communication
> through a loopback device is not that slow...

Well, if Bioware will provide the ability to use sockets from within
the scripting system, I'll take it.

Actually, I'm contemplating some kind of extension to the Avlis
system, where instead of just writing sql queries to the shared
memory from the scripting system, there is the possibility of other,
more robust IPC, in that case, the wrapper would probably expect
some kind of formatted data, and provide the capability to relay
that data over a socket connection (think xml-formatted data most
likely, with the wrapper providing rudimentry target switching
depending on the data payload).

The only real limit is that it would be complex to have more than
four event sources within the scripting system since the IA32
architecture only provides DR0 - DR3 registers for hardware


MUD-Dev mailing list
MUD-Dev at kanga.nu

More information about the MUD-Dev mailing list