Persistence?

[AcadiusLost]

I've been talking to Indio about NWNx4, he's been using the persistent database functions it provides for several months now without problems. Are these a passable workaround for the unreliable CampaignVariable functions of NWN2? As such, should we be working them into the larger ACR framework? I think we've been unanimously in favor of using NWNx4 so far.

[indio]

This is just an example script to see how the DB get's written to under NWNX4. The proof is in the pudding. If you've been on the 003 beta server, you'll have noticed quest persistence. So whatever is wrong with the SetCampaign functions is not affecting NWNX4.

Just some additional info. My host spec is:
Core2Duo 4200 @ 2.2
2GB RAM
WD 500GB HD
8000/384 bandwidth

Server stability is awesome. It rarely, if ever, crashes. The mod size is small, still under 200MB, but you can just tell that up to 1GB it's not even going to be breaking a sweat. CPU utilisation never goes above 5%, and there are no memory leaks.

Code: Select all

#include "ginc_param_const"
#include "ginc_var_ops"
#include "nwnx_sql"

void main(string sVariable, string sChange, string sTarget)
{
    object oPC = GetPCSpeaker();
	if (GetIsObjectValid(oPC) == FALSE) 
		PrintString("ga_local_int: " + sTarget + " is invalid");

	int nOldValue = GetPersistentInt(oPC, sVariable, "pwdata");
	int nNewValue = CalcNewIntValue(nOldValue, sChange);

	SetPersistentInt(oPC, sVariable, nNewValue, 0, "pwdata");
	
    //PrintString(sTarget + "'s variable " + sVariable + " is now set to " + IntToString(nNewValue) );
}

[ç i p h é r]

If you were planning to use the local CodeBase database bundled with NWN2, NWNx4 does indeed offer you a working alternative, but you'd naturally have to install (and administer) a suitable database yourself. However, since reviewing NWNx4 a few weeks back with Zicada (at both Indio and Zicada's urging), we decided that NWNx4 was in fact the best way forward for ALFA, all things considered.

On the infrastructure side, Zicada is already running a remote MySQL service, which I've been able to connect to and interact with from my machine. What we need to yet do is finalize a solution to mitigate our dependence on one machine and the risks that come along with it. Likely, the answer lies in some form of redundancy and replication, which I believe Zicada is on top of.

On the technical side, I've already started defining the main schemas for our application on the remote database and optimizing the database functions the application will use. What we'll eventually have to do is retrofit the existing ACR scripts that have been relying upon a variety of persistence mechanisms. My attention this past week has been on reviewing and compiling an ABR creatures release, so it's been an idle week on the persistence front, from my perspective at least. My mindset in defining the schemas has been first and foremost to facilitate reporting on anything and everything.