Heed's PC Tools and persistency- ACR Integration?

[AcadiusLost]

The newer release of Heed's PC Tools adds player-configurable text macros (up to 45 of them per player)- this is a great boon for the bardic PCs and the slower typers among us. However- to store this information, PC tools needs to write to a database.

The good news: There are three options coded already in PC tools. The information can be stored serverside using the OE database, stored as locals on items (saved when the PC is saved to the vault), or stored in an SQL database via NWNx4.

Each approach has it's advantages and disadvantages- certainly NWNx/SQL seems the obvious route, since we're already using it for all our persistency information. However, our ACR adaption of the NWNx/SQL functions mean that at least a few things need to be modified in the Heed's code in order to get it working. Also, this could begin to add up in terms of DB lag or access, pulling in or writing all the text macros on each login/logout. Heeds' seems pretty efficiently coded, but there is also the concern about DB bloat if we've got all this from all the PCs on all the servers piling up in the pwdata table. We could give it it's own table perhaps, though again, that's more modification of Heeds' code that will have to be maintained across updates. The plus would be seamless conservation of the player macros across servers.

The local variables method might actually be easiest in terms of maintaining Heed's code in it's minimally modified state, while still allowing crosserver persistency- but I'd heard some concerns with loss of local variables on items in some conditions - I believe that is in part why we moved away from PC skins in NWN2 for the ACR. There is also the potential concern about .bic size bloat, which can happen when you're storing a lot of extra information on item in PC inventories- text is notoriously inefficiently packed. We haven't crash-tested NWN2 with large bics over a laggy Netdrive vault yet to see if there are CEB problems yet, but I'd expect it will continue to be a concern for NWN2.

The OE database method could also be used to keep the base code intact- and the transactions would be local instead of queried out to the central DB server- but then we'd lose all the player macros whenever hosting changed, and players travelling between servers would have to rewrite them all from scratch on the other side of a server portal.

Thoughts, opinions?

[edit: added CEB concerns to the locals discussion]

[AcadiusLost]

Had some progress on this- looks like we'll be going with NWNx/SQL for the persistency. I added a new table to the schema, called heedspwdata, so the macro information can keep most of the settings Heed's expects, and should be minimal to maintain across tool plugins. Seems to be working well now, just have to add the table creation to the ACR initialization functions.

[AcadiusLost]

All seems to be working with this, I've got a builders' erf and some updated haks and UI to go with it- all but the erf will be available via the Worldgate as soon as we get the bugs worked out of it.

[ç i p h é r]

Had some progress on this- looks like we'll be going with NWNx/SQL for the persistency. I added a new table to the schema, called heedspwdata, so the macro information can keep most of the settings Heed's expects, and should be minimal to maintain across tool plugins. Seems to be working well now, just have to add the table creation to the ACR initialization functions.

Does this table only store player macros or does it store other configs as well?

[AcadiusLost]

That table stores all of the Heed's PC Tools information- timers, config settings, macros, macro labels, etc. It should continue to support Heed's as it is developed through later versions.