Ok I reviewed the sql INSERT syntax for characters and I found three problems:
1. line 310: HP should be Max HP (GetMaxHitPoints()), not Current HP
2. lines 313-314: Good/Evil and Law/Chaos are reversed
3. line 323: There's extraneous syntax between the charisma score and the booleans - looks like I forgot to remove a pair of single quotes that throws off the column count. This is, without question, the root cause of the failed insert, though I'm not quite sure why you don't see the sql output on your end.
If that doesn't fix the problem, I'll retest on my machine tomorrow w/o any preexisting records in the database.
I can make the corrections and see if that sorts everything out- I'm happy to commit it if I get it working, I've made at least one other change to mod_events_i that should go up as well.
Hopefully I'll get the hang of the SQL syntax again so I can catch these if/when they appear.
Is spelltracking retrofitted and/or fixed for restoration by class yet? I didn't see a table in the DB that looked associated with spelltracking, though I might have overlooked it.
There are a few odd entries in the "log" table as well- has my defective PCs dropping a few things they never had- one looks like a an ABR creature skin, the other was ACR_PLAYER_FLAGS. I'd have to find where the drop logs are being generated to hunt that one down.
AcadiusLost wrote:Is spelltracking retrofitted and/or fixed for restoration by class yet? I didn't see a table in the DB that looked associated with spelltracking, though I might have overlooked it.
Not yet. I'll get back to that come Friday (with my work obligations out of the way). I'm planning to use just a single variable to track spells per PC (a serialized array) rather than a dedicated spell tracking table with distinct spell use columns. There's just too many spells to do the latter I think.
Sounds like a good approach, we may want to think about consolidating other variables similarly as time goes on, so the DB and tables don't grow exponentially.
Made the corrections, but the SQL server has gone missing again. I think getting a copy of the table schemas (or functions to autogenerate them OnModuleLoad) is becoming a priority for testing at this stage.
Much appreciated, Cipher. Needless to say, we need a reliable SQL server before we have the Beta server(s) upgrading to the new ACR, as downtimes like this will make them all inaccessible.
If I get the local version going, I might try to replicate it on the machine I host 030 North Underdark with, as a fallback alternative for beta testing. ping is likely going to be much slower, but the data may be useful in any case. In the Beta stages, retention of the SQL data is less essential than it will be for Live- we just need some option, otherwise we're dead in the water every time that SQL server is offline (seems like > 50% of the time this week)
Ok the files are committed. FYI, I went ahead and made the sql changes I noted above as well just in case I wasn't entirely clear about what needed doing. The sql server is still down, so my commits are untested, but the sql is straightforward and I don't anticipate any issues.
I certainly agree about needing a reliable host. Unfortunately, that was Zic's department. Feel free to examine hosting and backup options on your end while we sort out the centralization details in Zic's absence.
So far, so good. The autogeneration of the schema went flawlessly, once I remembered to point the ini at "localhost" instead of feeding it it's own IP address. Seems to work fine so far, the fixes to the insert statement seem to have done the trick for now. Currently Characters doesn't have a boolean for IsDead, but I suppose it's not necessary.
I'll continue to test systems and see if I can generate any more SQL errors.
I'll also see about trying to set it up on my hosting rig, in case you want to test the spelltrack code.
Great. I had an IsDead boolean initially, but it seemed redundant between HP and Damage and ACR_PLAYER_FLAGS. If there's some purpose for it that you foresee, we can easily add it back in.
AcadiusLost wrote:Only really useful to work out if PCs are currently dead from looking at the SQL tables. Damage vs. MaxHP shows dead PCs as having 1 HP left.
Doesn't seem like a priority, though.
You're absolutely right, but at the moment, the "dead" state is stored in the ACR_PLAYER_FLAGS persistent variable. I was wondering if it might be useful to make that a somewhat permanent attribute of the character object (ie characters.flags or characters.status) rather than a seemingly disconnected variable in pwdata as it is now. Storing and retrieving player states will clearly move beyond the basic Get/SetPersistentInt() calls if we did that but I'm not sure how much of a consideration that should be really. Recording those flags in a dedicated bit field in the characters table would store a whole slew of states as enumerated in acr_i (dead, fatigued, staggered, mutilated, decayed, etc).
What do you think? A flags/status bit field is more multi-purpose than a simple IsDead bit, but perhaps this information is deserving of a place in the characters table.
I've put up an alternate SQL server, since the one Zic put up is still MIA (several days now). I'll PM connection information to anyone who is testing the NWNx4/SQL code- not sure if it will be workable for Beta, since it's a slow-upload cable internet connection, but it's better than nothing.
Allright, a few more bugs out of the way, a few more discovered.
I'm pretty certain we need to rethink using just the public CD Key as a reference in our database. We end up with conflicting information every time someone rolls up a new character (or a second character, if we're talking Beta or the OAS), and it makes testing a real pain, because it doesn't account for you ever encountering your past PC's remains. I understand we're going to want to make sure we have a way to catch anyone who loots their own corpse in Live, but we really need a unique identifier by character, not by CD Key. Other examples of CD-key based frustration are persistent quest or other variables, who treat a player's later PCs the same as their previous ones (even down to, say, access to bank accounts, persistent inn rooms, etc).
It should still be something we can derive from the PC ingame, and store on the corpse and body (and vice versa). Should we try just composing PC Name and CD Key? So long as we test PC name on new character entry to make sure it's unique, I expect it would work OK. I'd have to look into the options for string operators to find a way to return just the name from such a composed string (since we don't know the length of the name), but I think it would go a long way towards clearing up some of the death system conflicts. Of course, we'll also have to use the EncodeSpecialCharacters() function for it as well, to keep from getting errors on 's in PC names.
Does this sound like a reasonable transition to make? If so, I'll see if I can work it in tonight.
I'm not sure I follow, AL. Are you talking about the generic persistent data in the pwdata table? That has a primary key consisting of Name, Tag, and Key, which is supposed to be unique (if not, we can add a unique constraint). For a PC, that's the Character name, Player CDKey, and variable name, respectively. So, it's not possible to have any data conflicts across a player's characters.
Can you describe the actual problem you're seeing? If need be, we could use character ID as that's guaranteed to be unique to the character, or prefix the CDKey with it. ID-CDKEY for example.
BTW, did you have an opinion on migrating character status to the characters table and out of pwdata? Just curious. It's best to make that change now rather than later.
I'd have to find where the drop logs are being generated to hunt that one down.