Well, if you do a password like that as a "runtime" thing, it would be totally useless - what good is the ability to check a feat online if you have to get your book out to do it? But you might mean a one-time check rather than one done whenever you check the feats themselves.Spoony Bard said:[h3]Passwording[/h3]
The most complicated way is to have the user provide some proof that they own the book before viewing the material. This password would be something like "Open your book to page 123 and enter the 3rd word at the top of the 3rd paragraph." Alternately, the user could be required to enter the book's UPC code (the number beneath the bar code on the book for those unfamiliar with the term).
Problems:
Against a dedicated hacker this is more gesture than effective measure, but then again so is everything. A technical problem is that an extra datafield will have to be added to the users database (not so much of a problem, but it will require a shutdown of the server for about an hour to implement - updating 13,000 user fields is not a walk in the park).
An alternative to adding a field to the user table is adding a new table. That way you'd have:
User Table: {ID Number, User Name, Postcount, Whatever}
Feat Table: {Name, Description, Prereq, Source, Whatever}
FeatViewingPermissions Table: {FeatSource, UserID Number}
Then the software checks if there is an entry in the FVP table for the right intersection of FeatSource and UserID Number.