Spell Database by Mob- Does it exist?

kelben · 10/29/06, 2:28 PM

Does such a data base exist? One where the various spells a mob can cast are listed? I normally use thottbot or alla to look up spells by name but this doesn't always work (don't know/can't remember name, more than one spell by this name etc)

<Mob name here>
associated spells:
<spell 1>
<spell 2>
<spell 3>
.
.
.

The reason I'm asking is for learning about the various spells mobs use against us...in an easy to find fashion like casting times etc For when I don't have my combat log in front of me to reference. Its still a bit of a guessing game when using thot or all. A better way of phrasing this question would be to ask if I knew nothing about a mob is there some place I could look to find out which spells it can cast?

Darkmantle · 10/29/06, 9:57 PM

http://www.wowguru.com/db/mobs/plains-creeper-id2563 is an example on guru's database.

Drauk · 10/30/06, 8:00 AM

Speaking of spell database. Anybody ever thought why does client contains so much information about spells ? Let's take this for example - http://thotbott.com/?sp=7376. For all we know - threat calculation is done on server. Then why does client file contains information about agro reduction ?

Darkmantle · 10/30/06, 9:03 AM

Originally Posted by Drauk

Speaking of spell database. Anybody ever thought why does client contains so much information about spells ? Let's take this for example - http://thotbott.com/?sp=7376. For all we know - threat calculation is done on server. Then why does client file contains information about agro reduction ?

Do you wish to be lagged when you get burning adrenaline because your computer is recieving the spell description from the server? For maximum server performance you wish to minimise the amount of traffic to and from the server to the client so all spell description item models are all on your client. Yes threat is calculated server side otherwise players could abuse the hell out of it. The client files contain information about threat reduction/increase because they are descriptions of spells that we may see.

Drauk · 10/30/06, 9:08 AM

Well, i can understand storing spells descriptions and icons client side. However client file contains far more than just description

http://www.thottbot.com/?sp=21184

This is hidden buff, you can't see its description at all. And it not only contains an exact verbal description, but it also contains specifics of aura, and exact number. The client doesn't need this information at all, but still stores is for some reason.

Darkmantle · 10/30/06, 9:54 AM

Originally Posted by Drauk

Well, i can understand storing spells descriptions and icons client side. However client file contains far more than just description

http://www.thottbot.com/?sp=21184

This is hidden buff, you can't see its description at all. And it not only contains an exact verbal description, but it also contains specifics of aura, and exact number. The client doesn't need this information at all, but still stores is for some reason.

Yeah but if it didn't then the client would have to be told by the server everytime the rogue came on that it had this buff instead of the client already having it.

♦ Oggie · 10/30/06, 10:01 AM

Originally Posted by Darkmantle

Yeah but if it didn't then the client would have to be told by the server everytime the rogue came on that it had this buff instead of the client already having it.

I think his point is that since the data is irrelivant, why doesn't it just have a minor or pointless entry rather than a specific? It's not like any data client side can be trusted anyway, and the server does all the math, so why not simply a 'you don't need to know' type N/A in all that.

My only guess is because all those fields are expected to be filled up and present in both databases, and it's simply easier to maintain one database current across all versions of clients and servers than a public and a private one. Since some of that data (namely thinking of increased cooldowns) directly affects clientside performance, the data in that field can't just be left out in -all- situations, might as well give it to everyone just to simplify bookkeeping.

There's also the secondary possiblity that it affects theorycrafting in a positive manner without forcing the powers that be to actually state in bold text. I don't really buy that as a primary explanation, but it might be enough to keep them from going ahead and swapping to a dual database system.