Persistent World Clarity
Zuzubof
Member Posts: 9
I used to host a small world in the old NWN package and am eager to start it up again with NWN:EE. But I have questions that need clarity. In this instance, the idea of a "persistent" world. As I understand it, persistence means that lots of player "unique" player data is also saved on logout and recovered on login. In the old days, you couldn't do that. Then along came NWNX which gave some database/storage options.
Now I'm reading all sorts of things about "persistent" worlds and am curious. Has an NWNX-like capability been added to NWN:EE allowing us to save and recover such special information? Or have I mis-interpreted the definition of persistent world?
Now I'm reading all sorts of things about "persistent" worlds and am curious. Has an NWNX-like capability been added to NWN:EE allowing us to save and recover such special information? Or have I mis-interpreted the definition of persistent world?
0
Comments
Also worth mentioning again that NWNX is and I'd assume will always be a community project, tackling things beyond the scope of the base game
These are the base game functions you can use: https://nwnlexicon.com/index.php?title=Category:Database_Functions
NWNX improves these a lot, but it is not necessary. I would however suggest using something like this:
https://neverwintervault.org/project/nwn1/script/persistence-facade-ee
As that will let you build using the native database, and then if you hit a limitation, you can just switch to NWNX/SQL without changing any of your scripts.
Thanks so much for helping clear all my cobwebs.
Many old scripts used the old database to store player and character variables. The common technique was to use both local variables and external variables, I think by retrieving an object from the database so you didn't have to make many read operations. The data was then saved locally for use and exported at certain events to preserve changes over resets.
Saving variables to inventory items may also be a sufficient solution.
First off character persistence:
This was accomplished in scripts generally by doing an 'export' of the player object usually scheduled every few minutes. This could run while the player was online and playing and was pretty invisible in operation. This saved the character themselves and all their associated equipment and gear and any variables that were stored on that character.
Module Persistence:
This is a bit tougher, the entire module could actually be 'saved' at any time although this did prompt up a 'save' loading screen even on clients when it was occurring. This wasn't used often in Persistent worlds because it saved changes that had occurred in the module. If you had things in your module you hadn't designed to respawn and saved the module then that creature or lewt or whatever was gone, restarting the server and hence module regularly was a method of clearing out debris and reloading. Characters and their progression were retained separately and the module itself was refreshed to its original state. If you did 'save' the module and reload it was reloaded at the state it was saved at, the operation itself interfered with gameplay and any degradation in performance would creep up.
Quest/Conversation Persistence:
This could be managed on the module by saving but another option was to manage the state of quests and completion and dialogs by saving variables on the player themselves. Have you talked to this npc before? Have you defeated trogdore already? Save a variable on the pc, regardless of a fresh load on an unsaved module, if you wrote the scripts and quests in such a way as to check for variables saved on a player then those quests were saved for that player if his player object was exported.
Database Purposes for Persistence:
Databases (nwnx and the build in biowaredb) were used for persistence in the game that wasn't something strictly on the player object itself. The singular most common probable use for the databases was to have an external storage of loot outside of the player object. Persistent chests where you could store your booty and have it reloaded later. It was possible to do many other things like for track ongoing events that had occurred in a module wide level that you wanted to persist. IE: opening up a new area for all players but only making it accessible once 'blarg the mighty' was slain, you could save those variables and information in the databases and track changes that were global to the module without using a 'save' mechanism on the module itself. This kept the module state clear and clean (and let you modify the module in the toolset without losing saves) and also allowed global persistence for events.
In fairness, I personally can't think of many modules or PW's that used database persistence for much other than loot chests. There is a lot you COULD do with them to have ongoing stories and module wide changes but most modules were pretty static in that regard. Changes were generally done by updates to the module in the toolset and just a 'new' version of the module continued after a specific point rather than using databases to identify changes. There were later on though, many modules that used the databases to manage player authentication and security after the master servers shutdown, and I believe it was useful too in modules like 'higher ground path of ascension' where players could successively unlock access to new races to make new characters (this was handled by database persistence as well).
NWN's native DB support is pretty primitive but you can get around that in many ways.