I've gained the vast majority of my NWN knowlege since I joined ALFA almost two years ago. So, I don't know much of anything about NWNx, except how to use its nifty profiler.
So for those that do... I'd like to discuss how deeply you think NWNx should be integrated into ALFA? My concerns with it have always been more or less the same: support and compatibility issues as NWN(2) is patched, and any bugs/issues it adds on its own. So the plan was to use NWNx4 for non-critical systems such as logging. I don't think there is any need for individual servers to maintain their own SQL database.
However, we really need a function to retrieve the system clock. This would make things much easier for us in a number of systems, and I don't know of an easy way to do that outside of NWNx. I've not seen any functions to retrieve the system clock on any of lists provided by OE or compiled by others. So it may be that we will end up having to integrate NWNx4 into the ACR in such a way that the ACR will require it to function. Can anyone think of other reasons why we should or shouldn't do this?
NWNx4 (Nerine?)
Moderators: ALFA Administrators, Staff - Technical
-
Nerine
- Skeleton's Knuckle
- Posts: 23
- Joined: Fri Jun 18, 2004 3:05 pm
- Location: Bucks, UK GMT+1 (BST)
NWNX Viability
Well first off, here's the latest news from the NWNX site...
Well first off, here's the latest news from the NWNX site...
It could be a while before it's fully supported...NWNX4 news
09-09-06 14:34
Age: 11 days
While I am not attending the Bioware forums on a daily basis, I couldn't help to notice a certain amount of confusion and uncertainty among PW developers regarding the availablility of NWNX for Neverwinter Nights 2.
This is the current status:
1) I have a clear statement from Obsidian: They want to support the PW community and they want to support NWNX. It will take some time before they will be able to fully support NWNX, but I am confident they will do so. Even if they would provide only the level of support Bioware did (read: zero), NWNX development will not be affected.
2) From what we know, it is clear that at least something like NWNX2 will be possible. The internal workings of the engine should have not changed much, and many of the functions we were able to hook in NWN1 should be present in NWN2 as well.
3) As it was (and is) the case with NWN1, the NWNX team and it's lead developer Papillon will offer continuous support for the community members who choose NWNX as their database persistency layer and magic-cauldron-for-everything-else. The idea behind NWNX is version indepence. Patches to the game will not break NWNX, and even if incompatibilities should arise, we are dedicated to fix them ASAP. We have supported NWN1 for four years now, and we will do the same for NWN2.
OE are on record stating they want to support NWNX - which is more than Bioware ever did...*from NWNX forum in response to a when will it be avilable query*
Well, that depends on what you include under the name NWNX4... I'd like to have an early beta version with just mysql connectivity around the time NWN2 hits the stores.
A graphical user interface, new features, and the other plugins will take more time to develop. But if the basic functionality is up, I'll start to give out subtasks to the developers who answered the developer call.
The 'old' method may well be prone to being broken by patches as with NWN1 ... I'm waiting on the built-in NWNX support as patch induced server crashes are a real headache to sort out.*from NWNX forum*
I am waiting for some special nwnx hooks in NWN2. While Obsidian promised to include them, I expect them to appear only in some patch #2 or #3. In the meantime, the old method will do just fine, though.
With the promised NWNX hooks, it would be safe to go as deep as we wanted, without them I wouldn't want to go beyond basic functions such as the logging and system clock access you mentioned.Ronan wrote:I'd like to discuss how deeply you think NWNx should be integrated into ALFA?
Nerine Galatea
ADM: ALFA006 - The Long Road
Member of ALFA2#07 - The Cold Lands
ADM: ALFA006 - The Long Road
Member of ALFA2#07 - The Cold Lands
-
ç i p h é r
- Retired
- Posts: 2904
- Joined: Fri Oct 21, 2005 4:12 pm
- Location: US Central (GMT - 6)
I think the decision should be based on how we weight the pros against the cons. Off the top of my head:
Pros:
* centralized storage and access (much easier to code around and maintain)
* standardized schemas (forces uniformity in how we store data across servers)
* performance (fast reads/writes)
* minimizes memory usage (no need to store everything locally on objects)
* easy web integration (ideal for reporting)
Cons:
* single point of failure (though with replication, we can minimize the risks)
* compatibility issues between patches (though nothing forces us to update until compatibility is restored)
* possible limit on future NWNX support
* requires technical competency
Anyone disagree with what's up there? Anything else you can think of to add?
Pros:
* centralized storage and access (much easier to code around and maintain)
* standardized schemas (forces uniformity in how we store data across servers)
* performance (fast reads/writes)
* minimizes memory usage (no need to store everything locally on objects)
* easy web integration (ideal for reporting)
Cons:
* single point of failure (though with replication, we can minimize the risks)
* compatibility issues between patches (though nothing forces us to update until compatibility is restored)
* possible limit on future NWNX support
* requires technical competency
Anyone disagree with what's up there? Anything else you can think of to add?
Cipher, I'm not sure if your refering to server-side DBs or central DBs?
There isn't any way to force data uniformity across servers that I can see, though. Builders aren't going to learn SQL just because all the servers are using a SQL database. I'm sure a lot of them would use NWN2's database, because its simply easier for them. If your refering to the ACR, then I would say that enforces its own data uniformity, though obviously some SQL features would be nice (transaction support, for one). P-storage use is out unless NWNx4 preserves local variables on items.
From what I've read, even the fastest NWNx2 databases still require things cached as local variables in-game for commonly-used variables. Is this not the case? The centralized access we are already planning on for the central DB of course, though I don't know of any mission-critical reasons we need it (mostly logging I think).ç i p h é r wrote:I think the decision should be based on how we weight the pros against the cons. Off the top of my head:
Pros:
* centralized storage and access (much easier to code around and maintain)
* standardized schemas (forces uniformity in how we store data across servers)
* performance (fast reads/writes)
* minimizes memory usage (no need to store everything locally on objects)
* easy web integration (ideal for reporting)
There isn't any way to force data uniformity across servers that I can see, though. Builders aren't going to learn SQL just because all the servers are using a SQL database. I'm sure a lot of them would use NWN2's database, because its simply easier for them. If your refering to the ACR, then I would say that enforces its own data uniformity, though obviously some SQL features would be nice (transaction support, for one). P-storage use is out unless NWNx4 preserves local variables on items.
-
ç i p h é r
- Retired
- Posts: 2904
- Joined: Fri Oct 21, 2005 4:12 pm
- Location: US Central (GMT - 6)
Central DBs.
AFAIK, storing data locally in-game isn't required with NWNx (in my experience), but it's certainly something you can use to further increase performance (ie manage data locally, but only write to database periodically) and might be required to handle things like updates to a player object on logout (storing a db ID on the PC since the object itself is destroyed - GetTag() and GetName() don't work but GetLocal*() does for whatever reason). I suspect this is a fairly common practice for those who use the bioware db to mitigate write times (fast reads but slow writes). We only need to store data locally (in-game) if we don't want to hit the database every time data needs to be read or written or to get around engine limitations (like the PC object being destroyed when the OnClientExit event triggers). For NWN2, I think we probably want to minimize memory overhead as our principle focus so a database that can perform fast reads and writes gives us the option to avoid extraneous local data storage. We don't have to do it this way, but it's a realistic option.
By forcing uniformity, I'm referring to the database tables themselves. If you're going to store data, it has to meet the requirements imposed by each schema.
AFAIK, storing data locally in-game isn't required with NWNx (in my experience), but it's certainly something you can use to further increase performance (ie manage data locally, but only write to database periodically) and might be required to handle things like updates to a player object on logout (storing a db ID on the PC since the object itself is destroyed - GetTag() and GetName() don't work but GetLocal*() does for whatever reason). I suspect this is a fairly common practice for those who use the bioware db to mitigate write times (fast reads but slow writes). We only need to store data locally (in-game) if we don't want to hit the database every time data needs to be read or written or to get around engine limitations (like the PC object being destroyed when the OnClientExit event triggers). For NWN2, I think we probably want to minimize memory overhead as our principle focus so a database that can perform fast reads and writes gives us the option to avoid extraneous local data storage. We don't have to do it this way, but it's a realistic option.
By forcing uniformity, I'm referring to the database tables themselves. If you're going to store data, it has to meet the requirements imposed by each schema.