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

Sean Kelly sean at ffwd.cx
Thu Feb 6 11:22:33 New Zealand Daylight Time 2003

On Wed, 5 Feb 2003, Smith, David (Lynchburg) wrote:

>>From the beginning:

>   - The Neverwinter Nights scripting language is crippled with
>   regards to IO.

>   - Use of an external persistence mechanism requires IO.

> Q: What would be an ideal method of linking the Neverwinter Nights
> server process to another process?

>   A1: SOCKETS!

>   A2: Shared Memory

In my digging to find out how to write a debugger, someone asked
what my purpose was, since they're fairly hard to code well.  I said
"I'm looking to build IPC into an app that doesn't have it."  Their
reply was "why don't you just use hacking techniques to patch IPC
code into the app?"  Though I gather it would violate the EULA, this
would be a much better solution than all this debug mode craziness.
I've kicked around the idea of putting some basic socket/pipe-based
communication layer in.  All you'd need were hooks into the
GetLocalString and SetLocalString calls.  Of course, patching IPC
into an exe is easier said than done.

> Well, is there any way to use the Neverwinter Nights server
> process memory as a kind of shared memory? We've already
> implicitly accepted that there will be two portions to the
> solution, a scripting portion and an external portion. A part of
> that external portion is going to have to exist locally (if we use
> a shared memory solution), and it would be agreeable if the
> portion that exists locally perform the kind of "server
> monitoring" functionality that is generally desired of server
> wrappers.

There is a kludgy way to do this that I haven't mentioned yet.  NWN
loads resources dynamically from the \override directory every time
they are needed.  I've found it's possible to swap in different
"foo.ncs" (compiled script files) to \override and the next time
ExecuteScript( "foo" ) is called it will execute the scipt file that
is in \override at that moment.  Thus it is possible to get data and
even executable code into NWN on the fly by swapping in compiled
script files.  The log file is a possible mechanism for getting data
out.  This obviously isn't very fast, but it works.

All in all, I think the lengths people are going to just to be able
to hook external code into NWN is absolutely absurd.  But BW doesn't
seem inclined to budge on its "no dynamic libraries" stance so I
guess we're stuck with it.  I'm starting to wonder about the
potential of the \override directory.  Just how many different
resources can be stuck in here?  Is it just NWScript and graphic
content, or can it be other stuff too?


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

More information about the MUD-Dev mailing list