NWNx4 and OAS2

Rusty · Post by **Rusty** » Mon Jul 09, 2007 12:56 pm

AL and I discussed this last night; essentially how to delineate the OAS and Live NWN2 servers on the database, and whether the OAS should be treated as a variant Live server within one db or as a seperate entity.

My instinct was to say that OAS2 should be dealt with entirely seperately to Live servers, as NWNx4 may be used in an entirely different manner for the two. However, AL points out that ACR changes would then require additional work to keep Live and OAS running consistently.

So, particularly from people who will be involved with OAS2, thoughts?

AcadiusLost · Post by **AcadiusLost** » Mon Jul 09, 2007 7:06 pm

Not sure whether many of the OAS2 / Admissions folks have post access here, actually.

It strikes me that the simplest way to separate the database for the OAS would be to just have a duplicate SQL schema that NWNx4 is pointed to for the OAS- so the systems can work just like they do for the main ACR (no special scripting arrangements needed), but the data is stored separately. On the OAS' side, it would just be one line changed in an .ini file.

On the server-side, it would mean supporting a second copy of the same tables, but that doesn't seem unmanagable unless there are performance bottlenecks.

Teric neDhalir · Post by **Teric neDhalir** » Mon Jul 09, 2007 7:21 pm

Just FYI I have no idea what you're talking about

I will, however, attempt to implement whatever you decide upon.
Teric

AcadiusLost · Post by **AcadiusLost** » Mon Jul 09, 2007 7:29 pm

In brief, from the next ACR release onward, we'll be storing our Persistent Data in a central DB, so it will all be cross-server and centralized. This is managed via NWNx4, which allows us to turn NWN2's calls to it's native DB functions (to store data in the /databases folder of NWN2) and turn them into internet queries or writes to a central SQL server.

Advantages of this include global tracking/enforcement of the one-PC rule, travel, logging, wealth, advancement, etc- as well as many other nifty tricks.

The question is whether the OAS should be treated as any other ALFA server in that respect, or if it should have it's own database, ideally viewable at will by Admissions staff (so exploiters/farmers/etc can be identified before decisions need to be made on whether to accept them).

indio · Post by **indio** » Mon Jul 09, 2007 10:36 pm

What sort of hit will that have on upload performance AL? Writing to a remote database every time a variable needs to be stored or, worse, retrieved?

AcadiusLost · Post by **AcadiusLost** » Mon Jul 09, 2007 10:43 pm

Supposedly, it's as fast as, or faster than, using the base NWN2 database. It's certainly something we'll be monitoring, as the speed may or may not be affected by the size of the tables- so we may have to address data bloat as time goes on, depending.

I know it's somewhat counterintuitive, but as I understand it, we're reaping the benefits of all the efficiency work that went into real-world opensource distributed database design. The amount of information we're reading or writing in each case is tiny- an integer here, a string there- most of the test queries I've done on the DB (hosted by Zicada) were completed in small fractions of a second (0.02 seconds) according to the SQL browser I was using.

Rusty · Post by **Rusty** » Tue Jul 10, 2007 9:34 am

Moved to NWN2: Brainstorming for access reasons.

HEEGZ · Post by **HEEGZ** » Tue Jul 10, 2007 3:52 pm

AcadiusLost wrote:Not sure whether many of the OAS2 / Admissions folks have post access here, actually.

It strikes me that the simplest way to separate the database for the OAS would be to just have a duplicate SQL schema that NWNx4 is pointed to for the OAS- so the systems can work just like they do for the main ACR (no special scripting arrangements needed), but the data is stored separately. On the OAS' side, it would just be one line changed in an .ini file.

On the server-side, it would mean supporting a second copy of the same tables, but that doesn't seem unmanagable unless there are performance bottlenecks.

I agree with this completely. Unless there are performance related issues I don't see why there should be any seperation. No need for more work if it's not called for. The OAS is still an ALFA server in most people's minds, if not a Live one. Also, I can see the advantage (initially) of testing these systems using the OAS during Beta and initial public access. We might learn some lessons and work out bugs as it is highly likely to see alot of traffic before any of the Live servers go up.

AcadiusLost wrote:In brief, from the next ACR release onward, we'll be storing our Persistent Data in a central DB, so it will all be cross-server and centralized. This is managed via NWNx4, which allows us to turn NWN2's calls to it's native DB functions (to store data in the /databases folder of NWN2) and turn them into internet queries or writes to a central SQL server.

Advantages of this include global tracking/enforcement of the one-PC rule, travel, logging, wealth, advancement, etc- as well as many other nifty tricks.

The question is whether the OAS should be treated as any other ALFA server in that respect, or if it should have it's own database, ideally viewable at will by Admissions staff (so exploiters/farmers/etc can be identified before decisions need to be made on whether to accept them).

Having access to this info would be helpful in the extreme for making membership decisions. It has traditionally fallen to a DM logging in and randomly catching someone in the act to raise a warning flag. I don't really see the advantage in not having the OAS use the same system as Live servers unless there is a performance issue.