We are happy to announce to the NWN Community that the Avlis Team has developed a real-time Open Database Connectivity (ODBC) interface. Unlike previous systems, which utilize either tokens to hold information or creatively read the log file and re-compile it into the module, the Avlis Persistence System (APS) and the underlying NWN Extender (NWNX) read and write information from a database on the fly and make information stored in the database available in real-time. Supports Windows NT, 2k, and XP.
[Update v1.12: fixed a potential problem when NWN server crashed] [Update v1.21: added code to APS and NWNX that prevents potential startup problems] [Update v1.22: added support for italian, some statistics, SQL error messages, and some minor fixes.] [Update v1.23: NWNX licensed under the GPL, source code is included.]
Posted by Gonzo_og at 2010-01-12 11:39:02 Voted 10.00 on 01/12/10
Not enough votes for this. _________________________ stuff
Posted by Jaysyn at 2007-05-30 05:44:23 Voted 10.00 on 05/30/07
One of the most valuable additions to NWN. _________________________ -=Jaysyn=-
Posted by xtrick8 at 2006-08-03 14:28:18 Voted 10.00 on 08/03/06
What can I say. NWNx and APS are already used in so many PWs. I installed it into my mod and converted to a PW with the minimum of fuss. There are so many extensions on top of this one, that it is a must. I am using NWNx with mySQL and found that it hums along nicely. Great work NWNx and APS team. You just HAVE to make this available in NWN2 or our future PW would be in jeopardy :-)
Posted by xtrick8 at 2006-07-31 07:28:27 Voted 10.00 on 08/03/06
This is really neat. Is there some way to store all the placeables from an area, and retrieve them later ?
This is a compilation of the old system into a single score. There were 66 that made this score of 9.16 then rounded to 9.
Posted by Warelock ( ..xxx.xxx ) at 2003-04-11 11:24:00
One thing I've noticed is that it doesn't do stackable objects. I had to find someone's workaround that fixed that. Then what happens when you place a rod/staff/wand item with no charges in a persistent chest? It stores only the tag of the item's blueprint in the back-end database. What this means is that you then get the item back from the chest and it's fully charged because its giving you a brand new copy of the item based on the blueprint which is fully charged! Ack! I had to add something disallowing a PC to put a rod/staff/wand into a persistent chest. A DM can do it though. If there was a function to query the number of charges you could store it in the record. You'd also have to have a function to modify the item's charges after you created a new one from the record. As far as I can see there's no way to do that.
Other than that, great job!
Posted by Tarsinge ( ..xxx.xxx ) at 2003-03-07 01:38:00
Great, thanks.
Maybe you should update the main topic to make it more
visible ?
Posted by Papillon ( ..xxx.xxx ) at 2003-03-06 15:39:00
Tarsinge, NWNX2 has been released several days ago.
lookie here.
Posted by Fehu ( ..xxx.xxx ) at 2003-02-28 08:14:00
Finally! I have been away from NWN since the end of
November frustrated by the lack of persistence. I am so
happy that someone has tackled this difficult task.
I am wondering though if we should wait for the 'official'
version of DB integration. I would hate to spend days
building this into my mod and then have to redo the whole
thing when Bioware finally gets its act together.
I will at least wait for NWNX2...
THANKS!!!
Posted by DragonTayl ( ..xxx.xxx ) at 2003-02-28 05:20:00
Ok, thanks for your fast reply, I look forward to seeing
NWNX2!
Posted by DragonTayl ( ..xxx.xxx ) at 2003-02-27 20:58:00
I am having an odd problem. I love the system and have
fully integrated it into my PW, however when I INSERT or
UPDATE locations, an unusual thing happens. Somehow it
seems as though the memory pages for the NWNX1! variable
don't clear fast enough. Here's what I see:
1) System checks to see if the record exists.
2) Systemp attempts to send a SQL call (this example is
update, though it happened with insert too)
3) System sends the first 51 characters of my SQL syntax
(plus the NWNX1!REQUEST! would make 64 bytes), then
completes the text with the rest of the original check to
see if the record exists.
4) System sends the correct SQL syntax.
Is anyone else having a problem like this? It became
noticable because the syntax lined up just enough in one of
the calls to WIPE OUT ALL EXISTING DATA in my table.
Here's example output from NWN Extender:
* Got request: SELECT player FROM taneeadv WHERE
player='DragonTayl' AND tag='DragonTayl' AND name='lRecall'
* Sent response (10 bytes): DragonTayl
* Got request: UPDATE tanjeeadv SET
val='#AREA#TowerRoadForestValeyl' AND tag='DragonTayl' AND
name='lRecall'
* Empty set
* Got request: UPDATE tanjeeadv SET
val='#AREA#TowerRoadForestVale#POSITION_X# (the rest was
correct, and stored the variable correctly)
I have a work-around where I store 1024 spaces into the
NWNX1! variable right before my second call, but it is only
a work-around. I don't know if this happens due to length
or what. I suspect the debug event is called after the
first memory page of 64bytes is passed to the server, but
then why doesn't it cut up all the variables over 64 bytes,
only this long one?
Any help would be appreciated.
DragonTayl
Posted by spider661 ( ..xxx.xxx ) at 2003-02-27 09:44:00
can you make a vender invatory presedent whith this????
Posted by Papillon ( ..xxx.xxx ) at 2003-02-25 02:41:00
The polish version is not supported right now. You can
easily add the necessary strings to the source code and
compile yourself a new version or you can send me
screenshots (email) before and after the module is loaded.
Posted by Phervers ( ..xxx.xxx ) at 2003-02-24 12:20:00
I've been using this tool for a while now. Firstly i was
using an english language version of nwn. Recently i've
installed polish version. and to my disappointment this
tool stopped working. It says waiting for module, and
nothing more happens. It's working fine with the english
version though. Maybe you can figure out why? Maybe it's
about the different charset in polish version.
Posted by Sykos ( ..xxx.xxx ) at 2003-02-20 17:47:00
Thank for for this system i'm waiting for a long time :)
I'll try in under windows waiting to the release of the
linux version
Posted by Quietus ( ..xxx.xxx ) at 2003-02-20 10:28:00
Thanks for the response, Papillon.
I was more interested in the performance of the context
switching -- swapping threads isn't free ;) But again, I
suppose I answered my own question, in that it depends
upon how much you're call out of NWN script and into the
debugger.
But, you mentioning async made me realize that a certain
category of calls from NWN into the debugger are one-way,
doing SMTP, or simply saving data to the DB. The NWN
script doesn't care for a return necessarily. In these
scenarios, you could easily queue the requst from the NWN
script to be done on another thread in the debugger, thus
letting the NWN server resume with execution sooner,
rather than having it wait for the DB access, or whatever.
Now of course, there are complexities to taking this
approach, but if performance is suffering due to the
number calls into the debugger, then this would be
something to look info... ah.. well, version 2 then ;)
Anyway, when I'm done with what I'm working on, I'll
share. Right now, my debugger is written in Managed C++,
and my DB access code in in C#. I've tested with a
SqlServer database, as well as Access. I don't know
anything about MySql, so I haven't done that one :)
Ah, this is such fun stuff!
-Quietus
Posted by Papillon ( ..xxx.xxx ) at 2003-02-20 01:55:00
Quietus,
moving information between nwnx and nwserver is relatively
cheap. Performance problems arise when the backend code in
nwnx executes some time consuming queries (like SMTP).
The reason for that is that nwserver is a single threaded
application that has no means to synchronize asynchronous
communication. I guess you could emulate something with
NWScript, but I doubt anything good would come out of it.
The bottom line is: When NWNX has to wait for the result of
a request, the whole server has to wait. This usually is no
problem, though, as most queries take only 20-30 ms.
Posted by Quietus ( ..xxx.xxx ) at 2003-02-19 21:48:00
Duh, sorry for last *empty* post...
Anyway, I'm curious what your performace has been so far
Papillon? I imagine is it directly related to the number
of transitions from NWServer.exe to your app. I don't have
a large server/mod to test with.
Anyway, I am working on a similiar version to utilize
different databases and support other functionality, such
as SMTP, for instance. It'll be quite interesting to be
able to send an email due to a NPC conversation in your
MOD. :)
-Quietus
Posted by FastFrench ( ..xxx.xxx ) at 2003-02-19 00:56:00
OK, thank you.
As my server has often 60+ players, CPU usage is a
critical issue for me (our mod is around 33MB). I'll make
some testing and let you know if I find any significant
difference. Anyway, the token solution allready takes
significant CPU :(
Posted by Papillon ( ..xxx.xxx ) at 2003-02-18 11:28:00
Fastfrench, I don't have a clue why your compiled
executable is smaller than mine - probably you have some
other versions of certain dlls oder libs.
The debug mode is key for NWNX :) Some fact about CPU
usage: 1) It doesn't affect most modules, e.g. all three
mods on Avlis (55MB, 35MB, 30MB) don't see a decreased
performance. 2) It DOES affect some "artificial" benchmarks
(calling SetLocalString very often or creating lots of
icons in one shot). 3) The "attach approach" slightly
decreases cpu usage but unfortunately also decreases
stability (e.g. look at the routine that searches the
memory: When NWN moved the memory locations around, the
code in the attach-case may not be able to find the new
location, whereas the old approach will find it).
Posted by FastFrench ( ..xxx.xxx ) at 2003-02-18 06:33:00
A few remarks/questions:
- when I compile the source code, there's nothing wrong
(just a warning on link, about PSAPI.DLL), but my
NWN_Extender.exe file is 'only' 52KB large instead of 60KB
for yours (for the release version, in debug mode, it's
much more). As I kept all options unchanged, I were just a
bit surprised of such a big difference.
- don't you think that the fact you start NWServer.exe in
debug mode could significatively increase CPU usage ? I've
seen several echanges about the fact the APS raised CPU
usage of NWServer.exe. Couldn't it be the point ? Maybe
that's the reason you tried to experiment another
alternative (#define AttachVsDebug) ?
FF
Posted by FastFrench ( ..xxx.xxx ) at 2003-02-18 05:01:00
Great, thanks :) As 1.28 is not allready available in
French, I'll finally have a look on APS. Maybe I won't be
able to live without it soon afterall...
Thanks a lot Papillon, I'll keep you informed if I can
find some good improvements out of it. But at least I will
include my server monitoring codes.
Posted by Papillon ( ..xxx.xxx ) at 2003-02-17 16:01:00
Often requested, now available: As promised, the source
code to NWNX is included in the current distribution of aps
(v1.23).
Now I'm pretty curious what will come out of it...
Posted by Silk ( ..xxx.xxx ) at 2003-02-17 09:52:00
@FastFrench: The new CopyObject function facilitates a Token based system. You're deluding yourself if you think that even a good token based system would make APS "not of much use anymore".
FYI: We're currently running a beta version of NWNX2 on one of our servers. Papillon has really outdone himeself again.
Posted by FastFrench ( ..xxx.xxx ) at 2003-02-17 03:24:00
With V1.28 (copyobject function) I feel like such heavy
tools like APS are not of much use anymore.
Hopefully I won't wait for APS source code anymore... :)
Posted by Arcanius_NWH ( ..xxx.xxx ) at 2003-02-16 17:20:00
aye we are using the latest, we are trying hard to narrow
down where it goes wrong but so far without luck.
just dont work.....
can you contact me on icq 3420449?
Posted by Darkhavin ( ..xxx.xxx ) at 2003-02-16 16:23:00
Arcanius, I have the same problem:
Found 6 bytes for requests, 16384 bytes for responses.
(stop) (start)
Found 6 bytes for requests, 16384 bytes for responses.
(rinse repeat 4-6 times)
then:
Found 1024 bytes for requests, 16384 bytes for responses.
What's up? (I've been using 1.22)
Posted by Papillon ( ..xxx.xxx ) at 2003-02-16 16:15:00
Arcanius, are you using the current version ? There is a
script in there (aps_ready) that makes sure no queries are
executed before NWNX is ready.
Btw, NWNX2 is on the way, which will take everything to a
whole new level. We won't see problems like this anymore ;-
).
Posted by Arcanius_NWH ( ..xxx.xxx ) at 2003-02-16 14:23:00
Has there been any serious testing as to why the
initialization stage sometimes reports 0 bytes for
requests? My module size problem now seems to be less of
that and more of certain areas breaking the init phase.
With hundreds of areas this is quite a bit of a pain to
test. Why would the request bytes reserve break and not
the send bytes reserve?
Posted by Darkhavin ( ..xxx.xxx ) at 2003-02-12 11:16:00
Pelemele:
The problem is, when they were created you used large tag
names that were truncated because they exceeded the size
limitation of the blueprint resref field. Check em.
Site
at 2010-01-12 11:39:02
