Neverwinter Nights API

[Lanthar D'Alton]

Okay, I don't know how much this has been discussed before, nor do I know if anyone's really broached the subject with the NWN 2 developers, but before they get much farther, I really think we need to put pressure on them to provide an API for us. Nothing too special... maybe a plugin hook of some kind, with access to certain nwn exported functions...

That way, when NWN 2 comes out, we can move straight into plugin development instead of waiting for someone to disassemble it and find the function locations...

Why post this here? Because I think the nwnx community consists of the most concentrated set of real programmers... every really good nwn system maker is a member, and I think as a group, we could do some good in convincing the NWN developers, even if they ignored other people asking. Heck we could even give them code for it probably.

So, has all this been said before? Have they seriously majorly resisted other requests? Can we put forth the experience and the code and point out the advantages if they release an API? As a rule, the developers of NWN have been in support of programs like leto, and other such external apps...

I probably should go read the nwn 2 forums and see if it's been mentioned, but I could burn a lot of time and still not find the right thread.

-Lanthar

[JeroenB]

I think this is a great idea. Papillon and I have discussed slightly about this before and decided that we should contact the development team of NWN 2. But as Papillon is now out on vacation, we should wait a week and see what he thinks about it.

[mfx]

I second that. Great idea!
_________________
MNXJ - Java API for NWN : https://www.sourceforge.net/projects/mnxj/

[Senalaya]

After my attempt on the Dragon Age boards, to ask for that, here some findings:

We need to determine, what -exactly- we would like to have. Some things, like direct OS or commandline access out of the game for example are 'no no's for security reasons.

1.) Data Access
Should the external app and NWN be able to modify data in the other's process? Or would it be enough to do writes only within the own process and give just read access to the other process?

2.) Triggers
With the hooks, triggering actions in the external app isn't that much of a problem right now, but the other direction is pretty limited. The 'wait for reply' or polling isn't really a nice solution. Would be an addition event on module level like 'OnExternalEvent()' be enough? Would we need a parameter like with the 'SignalEvent()/EventUserDefined'?

3.) Data Types
Would it be enough to support the standard data types like int, float, string or do we need support for the game-structs like itemproperty, location, etc or even custom structs/pointers?

4.) Security
Should the interoperation of the API be limited to the same computer, NWN runs on? NWN runs as normal user, would the external app require more than that? How can it be made sure, that this API isn't used for trojan or destructive use like deleting files, spying on cd-keys, etc?

5.) Support
Besides security, this is the 2nd major problem. What kind of support would Obsidian have to provide for that API? If it's about multi-platform, what involvement would Atari have?

...


After some discussions with Georg Z. and Tim (the other Torlak), I'd suggest to aim as low as possible. A lot of features would be very nice, but raise a lot concerns in regards of efforts, support and security.

[Orleron]

We also do not know what kinds of plugins will be needed. For all we know, NWN2 will have an excellent SQL database interface with array functions, hashsets, and half the other things we've made plugins for.

*shrug*
_________________
____________________
Blackdagger: The World of Avlis
http://www.avlis.org

The Confederation of Planes & Planets
"Go anywhere. Do anything."
http://www.copap.org

[PlasmaJohn]

Nobody, no one group can think of everything. Nor can they implement all the features they'd like to add, much less what the community would like to see. External API's are essential especially if the core engine has a serious misfeature like a single threaded script VM like Aurora.

With Aurora and nwnx, we can emit data from the game to external processes. We do not have an effective backchannel and are forced to poll. If we were able to inject our own events, we could rip out all of the idiotic AI code, all of the scripting, and reimplement it using real languages on scalable hardware.

I can think of the following wishlist items:
- A direct means to get data out via plugin or something like MNX
- A means for external processes to inject events (plugin or socket listner)
- API access to management console commands (scriptable reboots/restarts)

PJ

[NoMercy]

Firstly, I'd like nwscript to be able to do server admin, change the name of the server, set player limits/etc.. probably unlikely but it would be handy instead of having to change ini settings for each diferent module loaded as well as allowing greater in-game administration (eg blocking new logins when someone is causing annoyance without phoning up the server host)

Onto plugins..

*thinks* I know i'd rather use IP sockets, probably TCP simply because it would give some flexibility with regards running the 'plugins' on remote machines, having a blocking function (from the view of nwscript) would be useful, eg 'object GetReturnedObject( "NWNX", "SQL!SELECT obj..." );' could block the execution of a nwscript program until the plugin had sent a reply to the query back, this would allow simple quick things to be handled without anything more than a single line in the relevant script.

Also it would be a benefit if objects (and all other data types) could be sent and recieved asyncronously, so you could send a message out to the plugin along the lines of 'void SendString( "NWNX, "LOG!Pie is good" ); without any blocking, allowing the plugin to do whatever it likes with the string without holding up nwserver, similarly objects could be recieved, and handled in a similar way to objects being acquired by PCs (module event), eg GetLastStringRecieved(); GetLastStringRecievedFrom(); and mabie GetLastRecievedType(); to check what type of object/string/int was sent to the module.

Naturally some extra protocal would be needed, for connecting programs to authenticate with the server, and to set there connection name.


It might sound long winded, but it's probably just my explanation :)

Given those few bits, most things could be done, admitidly it's not going to be a high preformance hashset, or code profiler, but it would allow most of the simple database/logfile/etc handling.

[Papillon]

No planning for NWNX for NWN2 has been done yet. There are some ideas in my head, based on the little information that is available from Obsidian, e.g. they said the scripting will be compatible to NWN1, leading me to believe the basics NWNX depends on will not change too much.

They have also stated that it is too early for design decisions like SQL support or no, so I have not bothered contacting them yet.

What I would like them to do is to provide two or three functions for NWNX, that do nothing when called from NWSCRIPT without NWNX loaded, but can be easily hooked (i.e. they have an easily identifiable function signature). Two functions would be counterparts to Get/SetLocalString for getting data in and out, and another function would allow NWNX to add a script to the execution queue (for external event support).

I will contact them with that idea and see what they say. I think that is not too much to ask, so they might do something about it.
_________________
Papillon

[JeroenB]

Maybe something for INT's could be interesting too, just for a bit of speeds sake.

[Grinning Fool]

A couple of things I'd like to see in such an interface (some has been mentioned, but I'm reiterating because they're good points).

- Top on my list is event injection. I can think of no limt of uses for that kind of thing.
- The ability to send and receive all data types
- Both syncronous and asynchronous calls outside of the main proc. Combined with event injection, this would be powerful indeed.
- Basically everthing that NoMercy posted, skipping the admin stuff since that's not really plugin-related.
- Documentation on how threading will be handled -- i.e., will the data we receive in asynchronous mode be thread-safe?
- A defined interface for events getting emitted from the game, much as one exists for nwscript.