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.]
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 at 2003-02-2709:44:00
can you make a vender invatory presedent whith this????
Posted by Papillon at 2003-02-2502: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 at 2003-02-2412: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 at 2003-02-2017: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 at 2003-02-2010: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 at 2003-02-2001: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 at 2003-02-1921: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 at 2003-02-1900: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 at 2003-02-1811: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).
Site
