Persistency

indio · Post by **indio** » Mon Feb 26, 2007 5:24 am

Who knows what? What system, where are we at with it, should I not begin scripting (I make most things persistent in the main)? Anyone who knows anything at all would be a great help.

AcadiusLost · Post by **AcadiusLost** » Mon Feb 26, 2007 5:45 am

Ronan had a fair bit of code associated with persitency up on the sourceforge deal, though I'm not sure how much of it was tested. I've been tinkering with it somewhat, but been distracted today by the spawn system.

I believe you have access to the ACR2 code repository as well? Perhaps you could have a gander about as well, if you're eager to.

One thing that may need doing is looking into how to interface our persitency systems with NWNx4, as it wasn't available at the time of the code's authorship. I think we're pretty unanimous about wanting to work with NWNx4 for all of ALFA's servers.

ç i p h é r · Post by **ç i p h é r** » Mon Feb 26, 2007 6:32 am

We discussed persistence at length quite some time ago but I haven't returned my focus to it mainly b/c our attention isn't on scripting atm. Ronan did write some interface functions (for the Bioware database only), but they're essentially middle layer code and untested. I had to debug a set of them for death persistence and bypass some of the things he was trying to do, which weren't working. We'll need to revisit these once OE repairs the database read/write functions themselves (atm, they don't work at all) and figure out what we want to keep/fix.

As for NWNx4, we're planning to use it for centralized logging purposes (as you probably know) where it'll likely just be another part of Infra services. Daeftan started evaluating it not long ago, but the primary concern with having an ALFA wide dependence on NWNx4 is the level of technical expertise required to setup and administer a local SQL database (at the server level) by hosters. I think the use of NWNx4 in the logging system will bring us closer to some decision, but in the mean time, it would be beneficial to simply know if we have the technical competence/comfort level across server teams for local SQL installs. Otherwise, it's really a discussion between remote SQL DB vs local Bioware DB.

indio · Post by **indio** » Tue Feb 27, 2007 11:08 pm

Edit: Agreed with cipher in post below.

indio · Post by **indio** » Wed Feb 28, 2007 12:05 am

And here.

ç i p h é r · Post by **ç i p h é r** » Wed Feb 28, 2007 7:48 am

Just to make sure I understood you Indio, NWNx4 appears to be a source of lag in NWN2? Is this something you've observed or read about? I wonder if Daeftan has observed the same problems; His comments implied otherwise. Bear in mind that there's only a Beta version out still and that, according to Rob McGinnis, OE is building in script hooks for NWNx into their engine with the 1.05 patch. That should, if nothing else, level the playing field for access. I think NWNx will reassert itself as the performance king, if it isn't so now.

The one advantage that the Bioware DB had over NWNx in my estimation was the ability to save "objects" to the database, along with all the local variables. The preservation of local variables on objects is quite significant for a persistent world. Stick an item in a pChest and that item keeps all the data stored on it when retrieved at a later time. This isn't possible, or wasn't, with NWNx. It's yet another factor to consider right along with performance and complexity.

This will require more testing once the 1.05 patch is out so let's revisit it again then.

indio · Post by **indio** » Wed Feb 28, 2007 9:24 am

I've edited my posts..not sure what I was thinking now. NWNX4 sits on 0% CPU usage until a module heartbeat, when it jumps to 12%. It's no system hog.

I've been reading I guess mostly reviews and commentary of NWNX2, which is the one people say is a resource hog. Thanks for clarifying cipher.

indio · Post by **indio** » Thu Mar 01, 2007 9:56 pm

Some hopefully better recommendations:

- Rowell's Persistent Base Module: http://nwvault.ign.com/View.php?view=NW ... tail&id=63

This is a very thoughtfully designed module with a well-crafted databae that will suit our PW needs. Here are the basic contents of the tables:

CREATE TABLE `Table_Area` (
CREATE TABLE `Table_Auction` (
CREATE TABLE `Table_Bank` (
CREATE TABLE `Table_Bank_Vault` (
CREATE TABLE `Table_Calendar` (
CREATE TABLE `Table_CDKey` (
CREATE TABLE `Table_Character` (
`CharacterID` int(11) NOT NULL,
`PlayerID` int(8) default NULL,
`CharName` varchar(32) default NULL,
`FirstLogin` datetime default NULL,
`LastLogin` datetime default NULL,
`LastLogout` datetime default NULL,
`LoginCount` int(6) default NULL,
`TimeOnline` int(8) default NULL,
`Banned` int(1) default NULL,
`Deleted` int(1) default NULL,
`Race` varchar(32) default NULL,
`SubRace` varchar(32) default NULL,
`Gender` varchar(6) default NULL,
`XP` int(10) default NULL,
`GP` int(10) default NULL,
`Alignment` varchar(16) default NULL,
`OverallLevel` int(2) default NULL,
`MaxHP` int(4) default NULL,
`CurHP` int(4) default NULL,
`Class1` varchar(20) default NULL,
`Class2` varchar(20) default NULL,
`Class3` varchar(20) default NULL,
`Level1` int(2) default NULL,
`Level2` int(2) default NULL,
`Level3` int(2) default NULL,
`Deaths` int(6) default NULL,
`IsDead` int(1) default NULL,
`Abil_STR` int(2) default NULL,
`Abil_CON` int(2) default NULL,
`Abil_DEX` int(2) default NULL,
`Abil_INT` int(2) default NULL,
`Abil_WIS` int(2) default NULL,
`Abil_CHA` int(2) default NULL,
`IsOnline` int(1) default NULL,
PRIMARY KEY (`CharacterID`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
CREATE TABLE `Table_Count` (
CREATE TABLE `Table_Discover` (
CREATE TABLE `Table_Error` (
CREATE TABLE `Table_Faction` (
CREATE TABLE `Table_Faction_Player` (
CREATE TABLE `Table_Faction_Rule` (
CREATE TABLE `Table_Item` (
CREATE TABLE `Table_Location` (
CREATE TABLE `Table_Lootdrop` (
CREATE TABLE `Table_NPC` (
CREATE TABLE `Table_Player` (
CREATE TABLE `Table_RQS_Reward` (
CREATE TABLE `Table_RQS_Faction` (
CREATE TABLE `Table_RQS_Progress` (
CREATE TABLE `Table_RTS_Recipe` (
CREATE TABLE `Table_RTS_Component` (
CREATE TABLE `Table_RTS_Book` (
CREATE TABLE `Table_RTS_XP` (

Cipher, I really think this is a time-saver in lots of ways and urge you to check it out.

ç i p h é r · Post by **ç i p h é r** » Fri Mar 02, 2007 12:45 am

Thanks Indio. I'll have a look.

ç i p h é r · Post by **ç i p h é r** » Fri Mar 09, 2007 4:56 am

Just an update. There's a lot of ground work here that I think we can use to further our plans.

Zicada and I spent some time this evening evaluating the prospects of NWNx4 as an Infra utility/service for our project. The setup was a breeze (NWN2 server connected to a remote sql server) and it seemed to work flawslessly despite the distance between our two machines. Furthermore, NWNx4 now supports the storage and retrieval of persistent OBJECTS, which is something that was lacking in NWNx2. This will allow us to save objects to the database AND preserve any local data stored on them as well, much like what the Bioware DB offered us. This effectively eliminates any dependence we may have had on the Bioware DB.

I believe Zicada and I are of like mind here in that NWNx is really a foundation we should be building our game world upon. It's a staple in the community and incredibly well supported, as evidenced by the integration of NWNx functions by OE. There are certainly some downsides to consider, which we discussed (some preliminary ideas) and intend to mitigate as best as possible, but when weighed against the negatives, it's unquestionable that the constraints of a system without NWNx hold us back. We are a project of significant size and scope and we need to use tools that simplify the job of running it.

In the coming week, I'm planning to work with Zicada to discuss and flesh out database schemas for systems both in development and on the drawing board. Rowell's work should give us a good running start.

ç i p h é r · Post by **ç i p h é r** » Sun Jul 01, 2007 5:21 pm

For those interested, here's a brief summary of my progress to date on the NWNX retrofit effort:

* setup core MySQL tables and login processing: cdkeys, ipaddress, players, characters, servers, pwdata, pwobject, and logs
* setup NWNx4 persistence function library
* setup character event logging
* retrofit player status persistence: storing/restoring health, attributes, and location now NWNX based
* retrofit resting system persistence: resting, praying, and studying now NWNX based
* retrofit death system: death and dying now NWNX based
* retrofit spell tracking: needs to be rewritten to work around NWN2 function bugs

There are some minor quirks in the death system I need to sort out yet and some other relatively small changes I want to make, but I'm almost at a point where I can commit this for some real testing on Indio's beta server.

indio · Post by **indio** » Sun Jul 01, 2007 9:43 pm

Can't wait. Good work.