Quote:
|
Quote:
Quote:
Here's the current flow of how the spells are loaded:
All I'm doing is changing the last step to this:
So instead of parsing through this: Code:
3^Summon Corpse^PLAYER_1^^^^^^^10000^^0^0^5000^2250^12000^0^0^0^700^70^0^0^0^0^0^0^0^0^0^0^0^0^0^0^0^0^0^0^0^0^0^0^0^0^0^0^0^0^0^0^0^0^0^0^0^2512^2106^17355^-1^-1^-1^1^1^1^1^-1^-1^-1^-1^100^100^100^100^100^100^100^100^100^100^100^100^0^1^0^0^91^254^254^254^254^254^254^254^254^254^254^254^6^20^14^-1^0^0^255^255^255^255^51^255^255^255^255^255^35^255^255^255^255^255^43^^0^4^0^0^0^0^0^0^0^0^0^0^0^0^0^0^0^0^0^0^100^0^109^307^0^0^0^0^0^0^0^0^0^3^125^64^^0^0^0^0^0^0^0^0^0^0^0^0^0^0^0^0^0^0^5^101^49^52^0^0^0^0^0^0^0^0^0^0^0^0^0^0^0^0^0^0^0^1^0^0 Code:
mysql> SELECT * FROM spells_new LIMIT 1 OFFSET 1; EDIT: The main reason I started towards this in the first place is that different utilities, including the PEQ editor, EQBrowser (Allakhazam clone), etc, usually have you source a trimmed copy of the spells file into the database anyways. However, they have a tendency to step over each others' toes, because some use fewer fields than others. This was to A) help alleviate the conflict, and B) make it easier to customize spell files, including tweaking the vanilla Titanium spell file (since we all know it's not perfect). |
It wasnt broke, so why are you fixing it?
Youre just adding an additional level of complication IMO. Since there already exists Spells.txt editors so loading the spells into the DB for editing isnt needed and since the client has to have the same Spells.txt file as the server for spells to work correctly for both the client and server and since this list is loaded once upon booting the world and since your still going to want to load the spells into memory no matter which method you use,for these reasons and more there doesnt seem to be any point to doing this. |
Ya, that would definitely be useful for web-based tools. And if a tool similar to the Ailia/Bleh Spell Editor was made to edit the Table version, I think it could really make a nice option for spell file management. Plus, this would give the option to use mysql commands to mass edit the spell file if people wanted to do that for any reason.
The only thing I would recommend for this system would be a really simple way to convert the spell file to the table and then the table back into the spell file. Otherwise, custom servers might have issues when trying to make sure that their custom spell files match the custom spell files that their players downloaded for their server. If a tool was made similar to the Ailia/Bleh one for the Table version, it would be very nice if the same tool would also convert the file to table and visa versa. Since the spell data is loaded globally when the server starts, I doubt this would be possible. But, it would be really cool if we could have a command that would let NPCs use any spell effect with custom values at any time. Essentially making a custom spell in real time via Perl. I think the command could use the fields in the table and then also set a value for it, and then just use the effects from the source for those fields. So, maybe something like quest::spelleffect(type, value), or maybe an extended version like quest::spelleffect(type, value, range, target_type, duration_ticks, pet_name, icon, "description", "msg_cast_on_you", "msg_cast_on_other") or something like that. Kinda off-topic idea, but sounds like fun to me :) |
Quote:
puting them into DB will: a) makes need of 1 spell editor LESS b) keeps all server related things in one place |
Quote:
That being said, what is the real advantage of this change? You do realize it will create a performance hit, right? Currently, all spells are loading into shared memory when the server first boots. I think somebody said it reloads them when a zone boots or something but that is incorrect. Spells only get loaded into memory once. If they did get loaded when a zone boots, then you would be able to edit spells on the fly, which you currently cannot. Moving this functionality to the DB is going to slow this down considerably... Having everything loaded into memory is the fastest way to do something, loading from a DB is among the slowest. |
I don't think he's talking about reloading it every time someone tries to access a spell; it will still be loaded only once.
I'd say it's pretty likely they store it in a file similar to what they put on the patcher, perhaps bundled into a data archive. Here's my thoughts on this: The reasons for adding it to the database aren't really all that compelling if you ask me. Assuming this went into effect right now. -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. |
I don't think AndMetal plans to have spells to be reloaded from Db over and over again evetytime zone boots or someone zones. The spell will also only load ONCE. The reason for puting server side files in DB are for purpose to work with them
|
Quote:
|
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.
|
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. |
Quote:
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. |
First, I would like to clarify, I have been talking about loading the spells into shared memory, not loading info on the fly from the database (that's just resource suicide).
Quote:
PHP Code:
PHP Code:
Code:
DatabaseGetMax() Quote:
Quote:
|
I think it's a good idea as a supplement to tools but again I'm not sure it's the greatest idea for the base server. I don't want to discourage you if you really want to put forth the effort to not only create the database but create the tools to input and extract spells from it.
However I don't see much reason to actually put it in the server standalone is what I was trying to say, having a unified standard for tools would simplify their design considerably. |
Theres a millions ways to trap a mouse, but the snap trap works with 95% efficiency.
Personally, I think you should change to the DB method and it only with a importer and exporter app for the spells.txt file. |
All times are GMT -4. The time now is 08:19 PM. |
Powered by vBulletin®, Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.