Upgrade your account to a Community Supporter account and remove most of the site ads.

Reply to thread

Message: <blockquote data-quote="spacemonkey" data-source="post: 1135416" data-attributes="member: 13180">I had been thinking of just doing a separate 'system' attribute, to group everything within its own magic system if need be, but that raised the problem of making a template for each magic system, or having all fields present, even if that magic system didn't posess them for display purposes (a blank CastingThreshold on the regular spells, for example). Or at least putting in a bunch of 'if it has X, then put X in, if not...' statements, which would need to be hard coded in probably.The attribute group seems a good way to 'template' the spells right in the db, so I'm all for it.  With that in mind, would we move the School back into the main spell table, or leave it as an attribute?  I'm still in favor of the latter, if only because those spells that don't have a traditional School wouldn't need to have a blank field there (or extra handling to display them without the blank field).As far as system support goes, I certainly don't think that we need to encompass anything larger than d20 (it's a big enough project as it is <img src="https://cdn.jsdelivr.net/joypixels/assets/8.0/png/unicode/64/1f609.png" class="smilie smilie--emoji" loading="lazy" width="64" height="64" alt=";)" title="Wink    ;)"  data-smilie="2"data-shortname=";)" />)  and I haven't seen anything d20 that doesn't have at least range, duration, etc.. standardized, though it could conceivably happen.  It's really a question of defining the scope of the DB and the project.  I'm usually in favor of flexibility for the app, but there comes a point of diminishing returns.  I would draw that line here, and if there are some spells that break it in the future, we could add a few special attributes for them if we really thought they should be included... but if they don't have range, duration, etc.. then they are probably different enough to cause other problems anyway.---Those issues aside, I had been meaning to add a field to my database, and now seems like a good time to do it, if changes are being made anyway.  An Eratta field is needed, I think.  I had previously been updating the spells with eratta when I could get to it, and adding a note at the bottom of the description of what had changed, but I find it difficult to search for which spells have been modified already.  The eratta text itself needs to be integrated into the longdesc field, so perhaps a date field noting when the last eratta was applied?  Null means it hasn't been eratta'd, and you could update the field if there was more than one eratta (as I have seen for a couple of spells).  The date would be based off when that particular eratta was released, to avoid confusion.The only real problem I can see with this is that it may not always be easy to locate the date eratta was published, and could be confusing to determine solely on that if eratta has been applied.  You can always look at the spell to see if it has been changed, however.---Another field I find handy to have is a 'verified' checkbox/date field (I prefer date, really - just for the extra info).  Mistakes can and will be made when entering data, especially if it is scanned/ocr'd.  It is a very slow process, but I would like to eventually hand-check every spell to verify that it is exactly the same as the book it was pulled from.  Maybe I'll force my players to do this one.. 5xp per spell, get crackin' <img src="https://cdn.jsdelivr.net/joypixels/assets/8.0/png/unicode/64/1f609.png" class="smilie smilie--emoji" loading="lazy" width="64" height="64" alt=";)" title="Wink    ;)"  data-smilie="2"data-shortname=";)" /></blockquote>

Verification