SetCampaignInt
CommonerX
Member Posts: 7
Hi,
first time poster, fresh builder with basic programming knowledge.
The function
results in no new record in the database, when the players xp is zero. Nor does any other int with 0 value.
Whereas
both work. Or at least both lead to the result
Is this wad or am I missing something?
first time poster, fresh builder with basic programming knowledge.
The function
int iXP; iXP = GetXP(oPC); SetCampaignInt("XP","PLAYERXP",iXP,oPC);
results in no new record in the database, when the players xp is zero. Nor does any other int with 0 value.
Whereas
SetCampaignString("XP","PLAYERXP",IntToString(iXP),oPC); SetCampaignJson("XP","PLAYERXP",JsonInt(iXP),oPC);
both work. Or at least both lead to the result
INSERT INTO "main"."db" ("payload") VALUES (X'43504442030000000200000002000000010000000000000028b52ffd200211000030'); aka CPDB............ ........(./. ... .0
Is this wad or am I missing something?
0
Comments
While only the original programmers of the system could confirm my speculation, I believe it was done this way just to save disk space.
Thank you for answering. This has a certain logic to it, although a bit sloppy and not completely without issues.
As information, a test run with
returned with "You have 0 XP."
EDIT: typos
It looks as though you are setting the variable "PLAYERXP" in one campaign database ("XP") and then trying to retrieve it from another ("AVATAR_PERSISTENCE").
Thank you. That is a copy/paste error. Actual script had it with the same name.
Long ago, I gave up on even attempting to use fancy parameters in databases, or for the most part, even attempting to store anything but a NPC into a database (with just one exception). Instead, the NPC holds an undroppable object which is given all of the parameters relating to a particular PC, and the file name for the database is comprised of the account name and CD key for the PC. To prevent database bloat, I always delete the database entirely before saving the NPC to a database with the same name.
I do it that way because if you save a new entry to a database and the new entry has the same identifier as a previously saved entry, it doesn't actually delete the previous entry but just marks it as unused and appends the replacement to the end of the database.
The only exception which I've ever used was a "flag" database which was never going to be changed. That was used to make a server restart on a real-world fixed schedule. The server would, every module heartbeat, attempt to read an integer from a database. Since the database didn't exist, the integer would come back zero and the module would continue uninterrupted.
The Task Scheduler in Windows was set to automatically copy a database into the correct folder at a certain time of day. That database contained the integer with a non-zero value which would signal the module to start the "reset" sequence, which used NWNX2 to complete the shutdown-restart sequence (after issuing warnings in plenty of time for players to finish what they were doing). Part of the shutdown sequence included deleting the database so that the server would not instantly go back into shutdown mode right after starting up again.
<SetCampaign> overwrites without further ado, even if the data type for the same VarName changes. At least this is the case with my tiny test databases.
I remember reading something about the database backend being changed, but didn't know what that implied. I'm glad to know that it finally deletes things when asked instead of leaving garbage behind.
My very little experimenting with the sql functions so far didn't bring up any issue. Even set up a DB with external means and adressed it with <SqlPrepareQueryCampaign> and <SqlStep> without problems.