Hi there,
I’m trying to troubleshoot a weird problem with the character persistence on my module and I want to view the sqlite that is saved in the player file as I believe it may not be saved correctly, however when I look at the bic in gffeditor it doesnt give much visibility into this. Is there a tool I can use for examining this data so I can confirm or deny whether it is in the file correctly?
I have a tool to view SQL lite here:
Works with Win10 / EE. I don’t know if the Website still exists.
What does that mean: “SQLite placed in character file?”. A database file within the character bic? Most unlikely. To view the character file you may use Leto.
What does that mean: “SQLite placed in character file?”. A database file within the character bic? Most unlikely. To view the character file you may use Leto.
When you use sqlite you can attach it either to a general campaign DB that’s saved with the module, or with the player file. I was trying to save player-specific stuff to the player file.
Uh, that’s something I probably don’t want to know 
But I guess that standard tools as above can’t handle the resulting file format. DB browser for SQLite works fine with Campaign Databases and individual databases (such as a persistent storage). You can create any database with any name in NWN. Maybe the “embedded” stuff is stored separately under a player-ID?
Maybe its worth backing up and starting from the basics, I might not be creating the database properly to begin with. Is there a preferred way to create character-specific databases?
You will need to determine your own preferred way since that is a preference…
Personally, for my PW I store a lot of stuff on the PC skin object. That let’s me see it with tools that work with gff files and just use normal nwnscript variable commands in game. However, I don’t do that for location persistence, hit points, PC state (e.g. dead) etc. I use nwnx and can access the database even when I can no longer access the PC object (onclientexit for example). The tables in the database have player and character ID fields as indexes. This allows easy access directly from sql tools out of game (in this case it’s mysql not sqlite but same idea).
The built in sqlite database stuff is new. I don’t have any experience with that. There may be those who do here.
What do you see in a gff editor (or converted to json etc) for one of your bic files with an embedded database? It must be stored in there as a gff field I’d think. You might be able to pull it out into something that looks like sqllite enough to read it.
It appears to be stored as a binary object named SQLite when I view the bic file in gffeditor, but it is unable to view that content. Is there a way to dump it for a normal sqlite viewer to poke it?
You can use nwn_gff from GitHub - niv/neverwinter.nim: CLI tools and nim library used in Neverwinter Nights: Enhanced Edition development to unpack the embedded sqlite3 database (see https://github.com/niv/neverwinter.nim/blob/master/nwn_gff.nim#L33 specifically). After extracting it, you can open/edit it with any sqlite3 application.
Thank you for this. Using that, I was able to diagnose that some areas were being saved as blank tags. Ie the tag was saved as just “”. Further examining this issue, it appears when I had imported into the module areas created by one of my fellows working on the project, it had given the area a blank tag, or rather, removed the existing tag, so if you were saving in that area, it would cause the game to have a stroke when trying to reload the player.
I should catch and isolate those instances, as well as correct the affected areas - but while I think I can handle it, I wanted to put record of what the problem is, in case someone runs into similar problems in the future. (hi google!)
Another tip: Strings inside sqlite databases are sometimes compressed by default, to save on disk space. If that makes it harder for you to debug issues, you can toggle that off in options … somewhere. It’ll only apply to newly written strings.
The actual use of that functionality is probably limited in practice (esp. since embedded sqlites in bic files are compressed anyways), but regardless, it defaults to on.
Thanks for that. It’s probably best to turn that off, I agree, so I’ll search that out and disable it. The gains of compressing something that’s already compressed are minimal.
