Crazy idea for spells...

[MNWatchdog]

Originally Posted by KLS

-You have slightly increased load on SQL server.
-You have slightly increased load times for spells.
-You have additional complexity when it comes to actually getting the spells to the client. (Now instead of modifying the spells directly you have to edit the database and then convert it.)
-You have increased database size.
-You don't really eliminate the need for a spell editor, you just lessen it if you're trying to change something simple. It will still be quite a hassle to heavily modify spells, especially many spells without one.
-You force people who wrote their spell editors to have to rewrite them for both systems, or you can continue to use them and then convert it over to the database but then what's the point.
-You've eliminated the need for a tool to need to write a spell file parser to get spells(which is incredibly simple btw).
-In my opinion you made it harder on new users who now have to try to figure out 'hey there's two systems for spells, wait do I need them both? I can't find the db table I need anywhere help!!'.

Lots of cons, a few pros. I personally just don't think it's a worthwhile idea.

Theres the more I mentioned. :p

[MNWatchdog]

Im guessing if youre going to do this, just do it one way and not have both methods available. All that does is double the number of spell editors that need to be maintained.

[trevius]

Ya, they would still be loaded into shared memory the same as they are now.

Even if the table wasn't actually used to load spells from when the server starts, it still could be a very useful table to have to spell editing. You would know every field and could quickly and easily sort by them to find all spells that use that particular field or certain effect. I think it would make finding spells for custom encounters a bit easier.

Another possible bonus to using a Table would be that it would be possible to include with the PEQ DB (though I doubt Cavedude would allow it). If it was included, it would be one less step to do when setting up a server (even though it is one of the easiest steps). And more importantly, it could be updated to correct or remove certain broken spells with the default Titanium Spell file. Not only that, but it could potentially be customized to add support for higher level spells as well as every spell from live past the point of titanium (around spell ID 8400). That wouldn't be too bad IMO. Sure, an edited spell file could be distributed with it, but an edited table is a little less iffy if you know what I mean. This possible bonus is pretty unlikely to happen, but it is something to maybe consider.

I think the main use for the table would be for web-based tools like PEQ Editor and others. With a full spell table like this, it would open up alot of options for web-tools. You could have them search for spells with certain criteria, or even go as far as editing the spells directly from the web-tool. AndMetal has a good point about multiple tools using variations of spell tables. I think his idea would be a good solution to take away the need to build extra spell tables for new tools.

I don't think it would hurt in any way for him to add this as an option to the source. Where you would need to change source before compiling by defining the spell table or something. It never hurts to have more options. If it started getting popular, maybe more positive uses for it would pop up.

[MNWatchdog]

Originally Posted by trevius

It never hurts to have more options.

Actually, this is often not true. Options as a rule are nice but also as a rule add complications and confusion.

This change CAN certainly be nice and allow more flexibility, but there is often a unforseen cost too.

Good example. I once wrote a macro to do some simple repetitive tasks. I enjoyed it, it did it job but I thought it could be made even more useful and I continued to develope and tweek it.

Eventually, it reached a point that I had to read my own documentation to remember how to use it as it had become so all encompasing it was no longer simple to use. Sure, it could do more, but there was a definate trade off.

PS I posted said macro after all this work and as I recall, noone seemed to use it was still to complicated and thus it was useless.