[10289] Creature models, using cache data directly. Att. DB devs!

[NoFantasy]

As many will know already, our model system has a design that does not allow us in a easy way to use cache data directly. The data need to be modified quite a lot and is not always easy to understand what to fill in where for the four fields in creature_template.

I basically want to change this system so that we can use data from cache directly, for two reasons:

* simplify the life of Database devs

* getting more accurate model for creatures in-game

We know that 80% of the creatures are easy, they have only one model. It's the remaining 20% that gives us heart attacks and sleepless nights.

It is not easy to determine how we can do this, but i think i am very close to a fair solution. In words, it can be narrowed down to this:

// if mod4 && mod3 && mod2 && mod1 use any, by 25%-chance (other gender is selected and replaced after this function)

// if mod3 && mod2 && mod1 use mod3 unless mod2 has modelid_alt_model (then all by 33%-chance)

// if mod2 use mod2 unless mod2 has modelid_alt_model (then both by 50%-chance)

// if mod1 use mod1

As this text imply, creature_model_info will get a new field, model_alternative. The purpose of this will be to fill with an alternative model for special cases. Unlike modelid_other_gender that stores the male/female, this may simply store an alternative (for example a critter that may have two models, but does not have a gender). This way we avoid mixing up the data with gender related models.

In addition, we all know that models for totems has always been a topic for discussion, they depend on the players team. This will be solved with a new field like the modelid_alternative; modelid_other_team.

Now, the question is really, what do we want? Adjusting the current code will break a lot, and will more than likely end up with a cataclysm, breaking things all over. The changes i want to do, is written using cache data only, with no modifications or current database values provided by DB projects.

Is it ok for you guys to change Mangos so that we can use model data directly?

The code written so far is

http://paste2.org/p/932047

It may be some lol-code in there, however it's the concept that is more interesting, how we select the native model (not that the two new database fields are not actually added/used in the code yet, but access functions are made as place holders).

Edit: below is the most interesting part, showing the code/function for actual model selection only.

uint32 ObjectMgr::ChooseDisplayId(uint32 team, const CreatureInfo *cinfo, const CreatureData *data /*= NULL*/)
{
   // Use creature model explicit, override template (creature.display id)
   //if (data && data->displayid)
       //return data->displayid;                           // DISABLED while working

   // use defaults from the template
   uint32 display_id = 0;

   // models may be categorized as (in this order):
   // if mod4 && mod3 && mod2 && mod1  use any, by 25%-chance (other gender is selected and replaced after this function)
   // if mod3 && mod2 && mod1          use mod3 unless mod2 has modelid_alt_model (then all by 33%-chance)
   // if mod2                          use mod2 unless mod2 has modelid_alt_model (then both by 50%-chance)
   // if mod1                          use mod1

   // model selected here may be replaced with other_gender using own function

   if (cinfo->ModelId[3] && cinfo->ModelId[2] && cinfo->ModelId[1] && cinfo->ModelId[0])
   {
       display_id = cinfo->ModelId[urand(0,3)];
   }
   else if (cinfo->ModelId[2] && cinfo->ModelId[1] && cinfo->ModelId[0])
   {
       uint32 modelid_tmp = GetCreatureModelAlternativeModel(cinfo->ModelId[1]);
       display_id = modelid_tmp ? cinfo->ModelId[urand(0,2)] : cinfo->ModelId[2];
   }
   else if (cinfo->ModelId[1])
   {
       uint32 modelid_tmp = GetCreatureModelAlternativeModel(cinfo->ModelId[1]);
       display_id = modelid_tmp ? modelid_tmp : cinfo->ModelId[1];
   }
   else if (cinfo->ModelId[0])
   {
       display_id = cinfo->ModelId[0];
   }

   return display_id;
}

[KiriX]

Hm...

We can get four random model from DB right now. Use modelid_A and modelid_A2 (for Aliance) - this 2 model (random). And for each model use modelid_other_gender in creature_model_info.

1 model - modelid_A

2 model - modelid_other_gender from creature_model_info for modelid_A

3 model - modelid_A2

4 model - modelid_other_gender from creature_model_info for modelid_A2

May be I'm wrong?

[A350fly]

Very interesting way to make data less DB dependant.

Arg, it seems that paste2.org is down

I don't really understand this case :

// if mod3 && mod2 && mod1 use mod3 unless mod2 has modelid_alt_model (then all by 33%-chance)

What happen if mod1 or mod3 has modelid_alt_model ? Is it just an arbitrary choice to use random model only when mod2 has modelid_alt_model in this case ?

[NoFantasy]

To the last question:

Two different creatures:

entry 24637: mod1=1557, mod2=12199, mod3=12200

entry 24853: mod1=1126, mod2=11686, mod3=22670

In the first case, we may add model 12200 as model_alternative for model 12199, and then we have a random selection between the three

In the second case, we do not want to use mod1 and mod2, since it should always be mod3. For this example, the invisible model 11686 should not have an alternative, and as result we will use 22670 always.

So yes, this is basically a way to make a pattern so that we can eliminate those we do not want, and in opposite case, make sure we get a randomness where it's needed/wanted.

Edit: @ Kirix: it's nothing wrong with the current system per definition, it works if you know what data to put where. This is however the main reason to change the system, it's too hard to maintain and it's too dependent on customized and hand made data for every creature.

[KiriX]

Edit: @ Kirix: it's nothing wrong with the current system per definition, it works if you know what data to put where. This is however the main reason to change the system, it's too hard to maintain and it's too dependent on customized and hand made data for every creature.

Thanks, Now I fully understand you.

[NoFantasy]

It may be easier to see the reason behind modelid_alternative with this:

SELECT entry, modelid1, modelid2, modelid3, modelid4, name 
FROM creature_template
WHERE modelid1!=0 AND modelid2!=0 AND modelid3=0 AND modelid4=0;

From this we can see that there are several patterns:

* male vs. female models

* invisible vs. infernal (and other models we can call place holder models)

* models with same gender and/or same model w/different appearance

- The first case is easy enough, we select random gender later in code.

- The second case has been source of more than one headache, it makes creatures appear with the place holder model, instead of the invisible as we expect. Since the new code require modelid_alternative to use model1, we simply won't add any alternative for model2.

- The third case i'm actually not 100% sure of, but there may be cases where we have a random selection between model1 and model2. If so, we simply define the alternative and will then have 50% chance to use it. Note how creature entry 328 has two models, one white(model1) and one brown(model2). Without alternative, we end up with the brown version, with alternative we end up with 50% to be white.

[NoFantasy]

I've posted some real creatures model data at a DB project forum, in case someone want to do supplemental research.

[faramir118]

Any thought given to totem model depending on race? http://www.wowhead.com/guide=3.3&models#shaman-totems

[VladimirMangos]

It done already by creature_model_info.modelid_other_team (used specially for totems currently)

[zergtmn]

Orc, Troll, Dreanei and Tauren all have different sets of totem models.

[NoFantasy]

Why? Whyyy! Clearly something changed in 3.3, i was not aware of this at all during the make and before it was committed.

Unsure how to adapt code for this change, but it's more clear now that we need even more explicit code for totems than what was added in this rewrite. I'm pretty sure something fancy will come up though

[faramir118]

The models are in the client data, but I think race-specific totems are for Cataclysm. Maybe we'll be ahead of retail?

[karmazyn]

Orc,trolls,and taurens has different model in 3.3.5 already

[Cobra101]

I had posted this very question in another part of the forums. How exactly can we go about this?

I don't suppose a case switch could be coded into the core to run a check on the player's race before dropping the things and have it pull or use data based on that?

As I said in my other post I'm no C++ guru but does that sound logical? Faramir's kinda right; and Karmazyn is. It's went into being in 3.3 and it's gonna get worse in Cata.

Currently, Alliance only have Draenei; but the horde have spereate totem models for: Tauran (Original Model) Orcs and Trolls.

P.S. As the Project-Silvermoon admin I love the idea as a whole; it's gonna save me and my team lots of time. ...and in the long-run, hair. lol

[NoFantasy]

The most logical solution would of course be to select model for race, based on the native model. The more generic it can be, the better of course.

Currently, it seems that making own storage as creature_model_racial VALUES

(modelid, race, modelid_racial) and drop the current modelid_other_team is a fair solution. I don't know if there are other cases where display model is selected by race other than totems, but if they do exist, a generic system like that should already be usable for it.

Edit: ok, it need more research. creatures already exist for race, and it can seem more proper to select model from the creature entries instead of defining a modelid directly for the race.

[NoFantasy]

Support for the above issues added in [10381]. Sorry again for not being aware of this in the first place.

Note that the system became a bit more generic and can be used for more than just totems. Hacks was removed for shapeshift/forms and are also using data from the new table. As for how to fill and maintain the new table, it's a job for database devs, but below are an example:

INSERT INTO creature_model_race VALUES 
-- dr
(4587, 1024, 19638, 0), -- water
(4588, 1024, 19637, 0), -- earth
(4589, 1024, 19636, 0), -- fire
(4590, 1024, 19639, 0), -- air
-- tr
(4587, 128, 37773, 0),
(4588, 128, 37768, 0),
(4589, 128, 37771, 0),
(4590, 128, 37769, 0),
-- or
(4587, 2, 37772, 0),
(4588, 2, 37767, 0),
(4589, 2, 37770, 0),
(4590, 2, 37766, 0),
-- dw
(4587, 4, 37752, 0),
(4588, 4, 37750, 0),
(4589, 4, 37751, 0),
(4590, 4, 37749, 0);

The new table may very well have other uses, where we expect some creature model to change depending an race (or team for that matter, team is simply all races that belongs to a team).

[Toinan67]

Thanks a lot NoFantasy you did a great job !

[DaViper]

I can't wait till this Idea is implemented

[VladimirMangos]

As NoFantasy write above you post. It already implemented in mangos repo sources.

[DaViper]

Yes Vladimir, but thats not what I was commenting on...Like I stated I can't wait till this Idea is implemented (Both in core and in DB) he stated the rest is up to the DB people to fill in.

[Cobra101]

I'll make sure my DB team looks over it and IF we need anything else put in we will; full credit will go to you for this of course. Thank NoFantasy.

[faramir118]

I assume the Orb of Deception falls under the category of 'other uses'