|
Trying to enter session for an event from last month (I know, Iknow, but I just found where I put the sign in sheet), and I can't enter two of the players. The system claims their character is the wrong type.
Checking one of the profiles, I noted he hasn't created that character yet (his -3) and designated it one way or the other. The other player hasn't connected an account to the number yet (new player).
Can you look into this? Please let me know if you need additional information. Thanks.
At the moment, characters must be registered before we can report the event. This is because of the new programs, we were having issues with folks creating a character for one program (say, ACG) and then playing that character in a different program (Core or RPG) and having it reported as such. This was doing Very Weird Things to the data.
We're working on a more graceful solution, but to protect the integrity of the data we had to put a restriction on reporting that matches the type of the character to the type of the scenario. Unregistered characters, because they haven't been created yet, have no type so we can't report them until they are registered and a typed character created.
We're working on a more graceful solution, but to protect the integrity of the data we had to put a restriction on reporting that matches the type of the character to the type of the scenario. Unregistered characters, because they haven't been created yet, have no type so we can't report them until they are registered and a typed character created.
Why not simply assign unregistered characters the type appropriate to the event being reported? At least then there would only be a reporting issue if and when a subsequent event of a different type is reported on that character. Right now you're foregoing a lot of data...at least some of which you won't ever be able to get back.
Is the idea that, by forcing people to explicitly register their own characters before they can be used, the character type is more likely to be accurate? I think that's a highly questionable assumption, since the owner of the character is the source of the data in either case.
Also...there are some pretty obvious normalization problems with your database.* I don't mean that as a dig -- truly, I don't -- but it seems like you have bigger problems in the data integrity arena than a potentially incorrect character type.
* For example, if I change a character's name after a session is reported, that session retains the old name, which means the session record contains a field storing the character name (rather than getting it from the character table as it should). This is a violation of second normal form. Further, it doesn't seem likely that is a performance optimization, either, because you know exactly where to find the name; that is, you don't have to perform a potentially expensive search.
The idea is that when they register their character, they will be forced to select a program (a character type). Then when reporting is done, we can look at that type and block the character from receiving credit for the wrong program.
Assigning a type on the fly when they report is a solution we discussed, but we came up with something a little more flexible. I don't want to go into details until we've finished and tested it. :)
The idea is that when they register their character, they will be forced to select a program (a character type). Then when reporting is done, we can look at that type and block the character from receiving credit for the wrong program.
Assigning a type on the fly when they report is a solution we discussed, but we came up with something a little more flexible. I don't want to go into details until we've finished and tested it. :)
Fair enough; thanks for the insight. Looking forward to the fix.