`creature_Template` And `creature` Need Rewriting (Imo)

Just throwing an idea out:

I was thinking, a template is supposed to be a foundation that other things are built on which implies the template should be basic. The creature_template table howver is far from basic. It has too many fields that make an entry specific which means a lot of them can’t be used for multiple spawns.

Take for example: name, subname, attackpower, trainer_*

By including these in a template, in most cases you make that template only available to one specific spawn which means you need a template for each spawn. These fields should be included in the creature spawn table instead.


Let’s say you wanted to spawn 10 Gnolls but you wanted them to have different stats.

Rather than have 10 creature_template entries and 10 creature spawns, creature_template should only contain the basics of what a Gnoll spawn should be (faction, model, etc.) and the creature spawn table should contain the specifics for that spawn such as name, attackpower, mana, hp, etc.

I know this will probably be met with a lot of resistance but we’re not really using a template for what it was designed. By rewriting the two tables, you could trim a lot of the “fat” out of the DB

There is still data that is in creature_template that (at the very least needs overrides in creature), however a lot of the fields that should (or could) be spawn specific have been allowed to be overridden in creature (look at the wiki /emoticons/default_tongue.png ).

Now, there are fields that you are listing that absolutely have no business in creature (name?!?) there is only one name per template – that data is gathered from an smsg_creature_query_response, and therefore blizz would never have a creature with the same entry number, but a different name. Stats are also something that for a custom server – maybe, but for blizz like, they are generated from a range just like they are now. For example if a creature has a level range of 60-65, then stats are scaled across those levels depending on what level creature was spawned. This is one of the FEW aspects of spawing that Trinity has correct. On offy, you will never come across two level 60 Bears with different stats.

– Brian

MrSmite: I think you should see what packets we have to send and receive (SMSG_UPDATE_OBJECT, SMSG_CREATURE_QUERY). creature_template is not like that just for the sake of “being like that”.

There’s also WDB structures and DBCs structs that take a roll in the way the table is done.

Most fields in creature_template are “static” and should not change for different spawns of the same creature, except for rare exceptions and because of that we had to move the 3 different flags to creature.

I have to disagree.

Well, I’d have to disagree. Packets don’t really matter since those can be parsed into the necessary table fields.

SELECT * FROM creature_template WHERE `subname` LIKE '%Alchemy Supplies%'; [/SQL]

This returns 33 rows that are largely identical (obviously name and such are different) with a few small details. The fields that are spawn specific such as name absolutely don’t belong in a template. When you spawn a creature based on a template, that’s when you assign the name and other spawn specific data.

Take for example a tree. All trees have roots, branches, foliage and bark but not all trees are Oak trees. So your template would contain the basics of what defines a tree. When you spawn it, you assign the name and other pertinent data (num_branches, foliage_type, etc.). I get that it’s an oversimplified example but that’s what a template is; a foundation.

But whatever, I certainly don’t feel like rewriting it, nor do I feel like arguing about it.

Yes, they do matter. One SMSG_CREATURE_QUERY per template, one SMSG_UPDATE_OBJECT per spawn.

A row in creature_templates defines a creature, a row in creature defines a spawn of the creature.

A creature cannot have more than one template, a creature can have more than one spawn.

Just forget that the table is named template. Wrong name? Maybe… it could be named something else. Tbh, I do not care.

MrSmite, as far as I know there is a sniffer that is publicly available that can sniff 4.3.3 (I hope blizz is still on 4.3.3) – I suggest you grab it, and look at the raw data. Trinity doesn’t just make the stuff up. When the client sends a CMSG_CREATURE_QUERY, the server sends an SMSG_CREATURE_QUERY_RESPONSE – that is the data that you get in WDB, that is (for the most part) what goes in creature_template. You also get a compressed update packet – SMSG_UPDATE_OBJECT_COMPRESSED (at least that was the way it was on 3.3.5a). The fields that are sent in that packet are things like flags (anything NOT found in WDB).

If you want to rewrite the spawn system, then rewrite it so that it is fully blizz like. Right now, we have pooling, and game events, and a mish mash hodge podge spawning system, that can for the MOST part emulate blizz. A proper spawn system (in addition all the dynamic stuff that I described in the other thread), would have a table with just coordinates, and an ID. That ID would link to a table of all the possible spawns for that location with the various values that could be possible for that spawn. For example, right now if we need a bear, a tiger, and a murloc that can all spawn at the same location, we have to pool them – that pooling should be built into the spawn system. All that aside, it doesn’t change the fact that template data is needed because there is so much that doesn’t change. And one more time, ALL of the data that is in creature_template comes from a CMSG_CREATURE_QUERY, and it NEVER changes. Well, we also have data in there that comes from the compressed update packets, but anything that isn’t static can already be overridden.

– Brian

I think you guys are misunderstanding me. I’m not arguing that the sniffs are wrong what I’m saying is they’re not stored properly. When the client sends a CMSG_CREATURE_QUERY, it doesn’t mean that all the data for SMSG_CREATURE_QUERY_RESPONSE has to come from a single table.

But after you mention all the other stuff involved, I’m certainly not interested in rewriting the entire spawn system.

— Canned message start —

The topic did not belong to the section it was posted in and was moved to Code Development.

— Canned message end —

Anyway previous subforum was to develop on sql not to talk about db structure /emoticons/default_tongue.png

That’s exactly our point, it would be outright stupid if it didn’t. Especially for the fields that you mentioned (name, subname). Those two, above all the others ARE static and should only be defined once per template. I would understand if you wanted to move the fields that are sent for each spawn in SMSG_UPDATE_OBJECT but even most of those are static per template, but you suggested moving around WDB fields. That’s a no no.

Well it says DB / SAI so I figured the subforum was for either DB or script

I guess I have a different idea of what a template is then. In my eyes a template should be reusable and specifics should be applied in the derived object. Much like a template class has methods that are common to all objects derived from it and those objects then get their own methods that make them specific and unique.

Creating multiple entries for Kobolds or Murlocs or Gnolls (etc.) doesn’t seem like a template to me.

Either way though, even if we all agreed, it would be more work than it’s worth to change it now.


DB fixes/SAI DB scripts you would like to see included in an upcoming update pack.


Damage needs to be removed from template, thats about it. I’ve spent my weeks trying to figure out damage formula and would gladly like to see someone else figure it out.